Short term help

I have spent a lot of time getting build, test, and deployment pipelines up and running. Most of the advice out there assumes that you are using one technology and you can just use "the build tool" for that stack. Reality tends to be more complicated than that, with many projects involving multiple languages, code generation, and extensive test set up.

What kind of things could your CI/CD process do for you? It depends on your needs, but things that have really helped in other places include:

• Making sure that CI/CD is managed in the code repository so that running the build locally and on the build server does the same thing in the same way, and the build can evolve in a safe, version controlled way just like the rest of your code
• Helping trace and encode the real dependencies in your code base to unlock incremental, cachable build steps and reduce overall build times with concurrency
• Split your test suite so tests can be run in parallel (yes, even integration tests) and then aggregate the results
• Use tools like Nix or multi-step docker/podman builds to create minimal containers that only contain what they really need
  • bonus extra: doing this with Nix also gives you development environments as code and reproducible deployment artifacts - same code in, same container out

If this is a new product/project and you just want someone to make all these considerations go away I can also build you a project skeleton with everything set up and ready to go for your preferred CI provider and deployment environment.

Putting together a new project, or have a code base that's moving from "minimum viable" to "oh - I've got customers"? I can review your plans, or, given your constraints and objectives I can put together a suggested system architecture for you.

It's worth noting that I don't have a personal axe to grind here. I won't tell you to use a "clean" architecture because that's my thing, or to use microservices because they are fashionable. Different architectural styles exist for a reason, and each has its own trade offs in terms of constraints you choose to accept in order to gain certain benefits.

I have the advantage of having helped architect and design solutions in a variety of styles in production environments.

This is a bit of a hybrid service that includes aspects of technology evaluation and code audit with a splash of domain driven design by example (so that I understand what you're building) - but zoomed out to look at "how do I put all this together."

For ecosystems I've built decent sized projects in (.NET, TypeScript) I can spend some time reviewing your code and pointing out things you may want to improve.

This isn't the kind of code review you'd do on an individual PR: this is the kind of code review where I can (as an outsider) come in with fresh eyes and point out broader patterns in your code base that may be problematic. I can also help you take your conventions and "traditions" and turn them into a coding style guide with (in many cases) automated tooling to help the team put it into practice.

Considering buying a new service, picking up a new programming language, or changing to a new database library? I can do the research and evaluation you need based on your requirements. I've been helping drive technology choices in organizations for well over a decade now, and I can help you spot the good, the bad, and the ugly of the options you're considering. I may even be aware of options you haven't considered.

At its heart, the promise of domain driven design is simple: a code base that uses the same language as the people using it do, so that developers and domain experts can accurately share understanding of what the code should do and why.

Actually doing domain driven design is not simple at all, because it is a process to help you model reality and it turns out reality has a surprising amount of detail.

I can help with the process of getting started with DDD, help lead the early exploratory meetings between developers and domain experts, and give advice on how to capture what you discover in code while keeping everything maintainable.

Event sourcing is a technique for capturing all the events that "have happened" and using those to calculate the current state of your system.

For example, if a customer of yours moves you may publish a CustomerHasMoved event when they tell you, and a CustomerAddressHasChanged event when you have finished the business process that manages customers moving.

This has enormous benefits for auditing, for being able to look at how the system has changed over time, and for being able to fix bugs "retroactively" as you don't only have the current state of the system but also all of the steps that got you here.

It also requires a slightly different way of thinking about your code base and some specific tooling to avoid a system that slows down over time. And it affects how you think about business constraints like data retention and the right to erasure.

As the saying goes: been there, done that. I can help you do it too.

I'm a huge fan of property based testing, and I'm more than happy to give interactive workshops on getting started with it in .NET, TypeScript, and probably other languages if you ask nicely. Why pay for this when you could download a conference talk about it for free (including ones I've given myself)? Because I'll use a piece of your code to get started with you will walk away with an up and running example in your code base. This will keep us focused on the reality of doing property based testing in practice rather than seeing the nice, easy, examples you tend to be shown in a 45 minute talk.

I do just write good code as well. If you need a self contained library or a small solution built, I can do that for you. Whether it is parsing an obscure data format, efficient immutable directed graph data structures, or just a nice F# wrapper around a dotnet library, I will make sure it fits the style you're asking for and is well tested. Significant discounts apply if the results are going to be released under an open source licence.

If you're starting a green field project, I can create a "skeleton" repository with a managed developer environment, CI/CD and testing story set up and ready to use. You and your team get to start with actually writing your product.