That constraint set the effort behind every improvement we wanted to make. Fast local development, reliable testing, a single deployment story: each had to be applied across every service, so the work scaled with the size of the estate rather than the size of the change. The improvements with the most leverage were exactly the ones the architecture made hardest to ship. It wasn't only slowing us down day to day; it was keeping the systematic, compounding improvements out of reach.

So over the following months we shrank it. We took roughly 400 deployable units down to around 160. No customer noticed, because the behaviour was identical on the other side. Internally, the day-to-day friction dropped and the high-leverage improvements we'd deferred became feasible. This is how we did it, and why the number that mattered wasn't the count we deleted but the work it freed us to start.

How we got here​

Earlier in Codat's history, we went pretty hard on microservices, tantalised by the prospect of small, independently deployable pieces to let teams move without stepping on each other, and we got the benefits it promised: independent deployment, blast-radius isolation, clear boundaries.

More recently, however, it became increasingly apparent that having so many fine-grained services was slowing us down and holding us back. Every shared library bump became a dozen pull requests. Every certificate rotation became hundreds. A long tail of services that no one had touched in months still had to be patched, observed, and kept alive. We were spending way too much time Keeping The Lights On.

The independence was also partly an illusion. Enough of the services were tightly coupled that we had, in effect, a distributed monolith: nominally separate deployables that still had to be released in a careful, coordinated sequence. A single meaningful change often spanned several repositories and more than one team, and inconsistent deployment patterns meant no two releases felt quite the same. Shipping became an exercise in coordination rather than engineering.

Merge first, fix later​

The goal was simple: rationalise our service domains and drastically reduce the number of deployable units within each, with each domain owned by exactly one team.

The decision that made it achievable was what we chose not to do. Phase one merged services and nothing else. No re-architecting, no consolidating databases, no aligning every service to whatever we now consider best practice. If a service owned three databases after a merge, it kept three databases. Untangling that is a separate data-migration project for another day.

In hindsight, this was a prudent call. Giving in would have turned a bounded job into an open-ended rewrite we might never have finished. Drawing the line at merging the units, and leaving everything else where it was, is what kept the work finite; consistency could come later, on a smaller base.

Approach​

We started by mapping the whole estate to find the natural domain boundaries. This was iterative rather than a grand up-front design: propose a boundary, test it against how the services actually talked to each other, adjust.

Once the boundaries were set, we identified the distinct set of deployable unit types and discovered that nearly every merge reduced to one of five consolidation paths between source type and target type. Windows App Services were retired, not carried forward. WebJobs and in-process Azure Functions became isolated Functions, which run in their own process on any version of .NET and, unlike the in-process model, emit the distributed traces we need to actually see what a background job is doing.

Moving from Windows to Linux surfaced a handful of subtle differences between the platforms: path separators, filename casing (a single mis-cased appsettings.json and the app refuses to start), environment variables that Windows treats as case-insensitive and Linux does not. We catalogued these gotchas along the way to help avoid them on future merges.

Merging two applications also meant merging two dependency injection containers, and reconciling every registration between them. The trick we settled on was to dump both service collections just before building the container and diff them, letting the difference tell us what the combined configuration needed to be, rather than reasoning about it by hand.

We also decided that if a merge target was not already running in Kubernetes, we would migrate the target to k8s first rather than migrating host infrastructure mid-flight. We updated our internal routing setup to ensure deprecated connection strings now routed to the new home of the merged service.

Leveraging AI to consolidate faster​

What struck us early on was how mechanical most of the work turned out to be: move the code, reconcile the references, fix the build, port the tests, update the Helm charts. It was repetitive and error-prone, and we started to realise it was close to the kind of work modern coding agents are good at, which usefully coincided with us rolling out Claude Code across engineering. Claude performed the merges directly: resolving namespace collisions, untangling conflicting DI registrations, porting unit and integration tests into the target project, and updating charts and compose files.

But being in the driving seat guiding Claude, we were still liable to miss steps or do them in the wrong order, relearning the same lessons. So we used Claude to build a merge tool, incorporating two stages into the merge process. The first stage executed deterministic C# to perform the mechanical steps, including preserving full git history by importing the source as a stack of branches, so git blame still worked across the merged code, and it rewrote namespaces and using-statements to match the target's layout. The second stage generated Claude prompts for aspects of the merge that required judgement, such as consolidating two appsettings.json files and resolving dependency/restore failures.

The part we came to rely on most was that it never touched a file in the target. Any conflict was copied in beside the original under an _Imported or _OLD suffix for a person to reconcile; the build was validated before we called a merge done; and progress was saved after each stage, so an interrupted run could pick up where it stopped.

We're not going to pretend it was hands-off. It still needed direction. Occasionally it would fixate on a symptom instead of chasing the root cause, and a human had to redirect it. But the balance had tipped away from mechanical toil and toward judgement, which was what we'd been hoping for.

What it unlocks​

We removed hundreds of deployable units and consolidated our estate onto a unified host architecture. Features that used to require a coordinated march across three or four repositories now land in a single pull request. Maintenance is cheaper for the obvious reason that there are fewer moving parts to maintain; we immediately started spending less time Keeping The Lights On. But perhaps the most exciting benefit is that all the improvements we've dreamt of making to move our estate forward suddenly have become way more feasible.

There's some relatively low-hanging fruit such as replacing legacy custom libraries with idiomatic .NET, which we're now chipping away at. But we've immediately started work on something much bigger: we're reducing our number of environments to two, local and production. Stick around if you want to learn more!

Splitting it up was a defensible decision when it was made, in a company that looked different from this one. We paid for it for a long time afterwards. This is what the bill came to.

What we thought we were buying​

The case for splitting a frontend is always an organisational one. Teams get blocked on each other, nobody ships without pain, so you draw lines through the product, hand each team a piece, and describe the result as autonomy.

What we got was narrower than that. Our teams could deploy without asking anyone, which is worth having. What they couldn't do was see each other. And the coordination we'd tried to remove didn't disappear, it moved somewhere more expensive. A merge conflict is cheap, because the two people who caused it fix it in ten minutes. A disagreement about the shape of an event payload, between two teams who own two repositories, takes a Slack thread, a ticket and a fortnight. We swapped a compiler error for a meeting.

The bill​

The biggest line item was dependencies. When each application builds on its own you don't get a dependency tree, you get a matrix: two versions of the framework, four different pins of the design system. A design system that exists at four versions at once is four things sharing a name. The browser pays as well, downloading the same framework code once per slice.

You could watch the language change under you as you moved between repos: a different TypeScript in each, a router a few versions adrift, one slice still running a React that had been end-of-life for almost five years. Nobody decided any of that. It's just what a codebase does when no single place has to agree with itself. The user paid for the split too, not only us: a page load could fan out into seven separate fetches for code, and any one of them failing was a blank screen, because there was no compiler in between to have caught it first.

One tree fixed that. An upgrade or a CVE patch is now a single PR, verified by a single CI run and applied everywhere. The volume of dependency PRs fell by roughly an order of magnitude, though the number matters less than the fact that upgrades stopped being optional. There's nowhere for a stale version to hide.

The second line item was debt. Splitting a system doesn't reduce technical debt, it moves it somewhere you can't see. A repo nobody reads, owned by a team that reorganised twice since, where it sits quite happily until it becomes an incident. In one repository you can grep for it. Codemods work again. So do atomic changes: you can alter a shared component and every caller of it in a single commit, with CI telling you immediately whether you were wrong, instead of publishing a version and waiting months for the last consumer to adopt it.

Our boundaries also got types. Custom events and conventions about what goes in the URL were contracts checked at runtime, which is a polite way of saying our users checked them for us. Merging the repositories turned them into compile-time contracts, and the first week surfaced an embarrassing number of bugs that had been sitting there for ages.

Then there's the overhead. Every micro-frontend carries a repository, a pipeline, a bundler config that rots, a test setup with its own flakiness, a deployment target, an observability config, a dependency tree, and a local dev story that somebody has to keep alive. Multiply that by however many boundaries you drew, and you've built a platform team's worth of undifferentiated work and handed it out, unfunded, to your product engineers. In one repo it gets done once, properly, by whoever cares most about it.

Consistency, and silos​

We used to chase consistency with process: a component library, guidelines, a review forum, a fair amount of evangelism. All of that is a sign the architecture is fighting you. You only need governance when the code can't enforce the thing you want.

Now the consistent option is the lazy one. There's one button. You use it because it's there, and writing a second one would be more work, and someone would ask you why in review. The seams a user could see went too. No more full-page reload when you crossed an invisible internal border, no more half-second of the wrong font.

While each team owned a repository, the repository was the edge of what anyone was curious about. Engineers didn't read code they couldn't run, and reviews stopped at the border. We solved the same problem multiple times, without anyone noticing. Now people wander. They read adjacent code because it turns up in the same search, and they'll open a PR against something they don't own rather than file a ticket about it. Ownership is still real. It's enforced by review requirements rather than by a repository boundary nobody could see past, and engineers can move between areas of the product without hitting an onboarding cliff, which fixed a staffing problem we'd been trying to solve with org charts.

New starters clone one repo and run one command. It used to take them days to find everything.

What we should have done​

We wanted modularity and we bought distribution, and those aren't the same purchase. Modularity is the good part: boundaries you can enforce, code that can't reach where it shouldn't, ownership that means something, changes that don't ripple outwards. All of it is available inside a single build, with tooling that's cheap and dull. Lint rules that enforce module boundaries. Tests that assert which way dependencies are allowed to point. Ownership at the folder level. Feature flags, so that releasing something and deploying it stop being the same event.

Distribution adds version boundaries and deployment boundaries on top of that, and unless you need them, they're cost. Deployment independence solves a deployment problem. If your deploys are slow or frightening, fix the deploys. Trunk-based development and a fast pipeline will have you shipping several times a day without splitting a single bundle.

We'd still split under some circumstances. If CI can't keep up however you cache it. As a strangler pattern to get off a legacy stack, treated as a transition and not a destination. If an acquisition leaves you with two products that share a domain and nothing else. None of that was true of us, and I doubt it's true of most teams having this argument.

Why this is on a careers page​

Taking apart an architecture you built is uncomfortable. It means writing down, where your colleagues will read it, that something you made carefully is now in the way.

Nobody had to defend the original decision in order to protect their standing. It was made with the information available at the time, and everyone treated it that way. The case for reversing it got written up and argued over, then tested with a spike before anyone committed. The engineers who'd built within the old architecture led the merge, partly because they knew where the bodies were buried and partly because being wrong in public isn't a career event here.

We build financial infrastructure. Our customers put financial products on top of our platform, and they need it dependable and boringly correct. That rewards engineers who care more about being right in eighteen months than about winning today's argument, and who'll look at their own old decisions without much sentiment and ask whether they're still earning their keep.

If that's how you'd want to work, you may be a good fit at Codat, and we'd love to have a chat. See our open engineering roles.

Why a blog?​

Codat builds the infrastructure that connects small business financial data to the products that need it. Behind that sits a lot of interesting work — distributed systems processing large volumes of financial data, integrations with dozens of accounting and banking platforms, and the day-to-day craft of shipping software in small, autonomous teams.

Most of that work never leaves our internal wikis. We'd like to change that.

What to expect​

Posts here will come from people across Codat, and will broadly cover:

• Engineering deep dives — how we've solved real problems, from API design to data pipelines to developer experience.
• Life at Codat — what it's like to work in our teams, how we run them, and the things we've learned along the way.
• Things we've tried — experiments, conference write-ups, and honest retrospectives.

If any of that sounds like an environment you'd enjoy working in, we're usually hiring — take a look at our careers page.

See you in the next post.