Platform Mismatch

Five engineers, one deployable, one database. Everything in one place.

It was the right call, and the reasoning matters, because this is not a story about a mistake. At five people you can hold the whole system in your head. Nobody needs a service boundary to know what anyone else is doing, because everyone is doing it in the same room. One thing to deploy means one thing to debug and one thing to roll back. The team shipped fast because the architecture had almost no ceremony in it, and ceremony is what kills you when you are small.

Fifty engineers now. Same architecture.

Nothing about the decision has changed. Not one line of the reasoning that made it correct has been refuted. The monolith is still coherent, still well tested, still doing what it was designed to do.

And it is now the largest single thing standing between that company and its next year of work. Twelve teams queue behind one deploy pipeline. A change to a shared model means a conversation with four teams who did not want to be in it. The test suite takes long enough that people batch their merges, so failures arrive in clumps and nobody knows whose clump it was. Nothing is broken. Everything is slow.

This is a different failure from the last one, and the difference is the point. Drift is when the value leaves and the label stays. Here the value never left. The thing still does what it always did, as well as it ever did. What moved was the ground underneath. The company got bigger, the team got bigger, the number of people who need to change the same file at the same time got bigger, and a decision that fitted the old shape does not fit the new one.

That is Platform Mismatch. Right at the scale you were. Wrong at the scale you became.

It is the quietest of these shapes, for two reasons that feed each other.

The first is reputation. This was a good decision and everyone remembers it being one. It is in the origin story, told to new hires as evidence that the founding team knew what they were doing, which they did. You are not arguing against a mistake, which would be easy. You are arguing against a success.

The second is that it works. A broken thing announces itself. This does not. It passes every test you have, because the tests check whether it does its job, and it does. There is no alarm for "still functioning, no longer appropriate."

So you get the worst state for an organisation to act on. Not broken. Just wrong now. Broken creates urgency and gives someone permission to fix it. Wrong now is a slow tax that everyone pays without seeing the invoice.

The tax leaves receipts, though.

Listen for the habitual workaround, the one normalised into how work gets done here. A step everyone takes, a queue everyone waits in, a ritual that exists to protect one decision. Ask why and the answer starts with "because of," and what follows is your mismatch. The same thing shows up in planning as "we cannot do X because of Y," where Y was a sensible call three years ago and has been true long enough that nobody hears it as a choice.

And watch where new work goes. When teams start building next to a system rather than inside it, quietly, with no strategy meeting, they are voting with their hands. Not because it is broken. Because working inside it costs more than working beside it, and that gap is the tax made visible.

Then comes the question everyone gets wrong, and I want to be careful here, because I was in this one and I did not argue it on engineering.

Someone proposes a rewrite. Rebuild it properly for the company you are now, ship the new thing. Where I was, the engineering case for that was good. On the technical merits it was probably the better answer.

I argued against it anyway.

A rewrite asks the business to fund a stretch where it gets nothing new. Not less. Nothing. And the honest pitch at the end of it is that you have roughly what you have today, built better, with the payoff arriving later if it arrives. No board hears that as an investment. They hear a pause with a story attached.

So the real choice was never rewrite against strangle. Slower but steady, or nothing for a while. Most businesses can only afford one of those.

That argument carried the room without much resistance, which is the part worth sitting with.

Because the strangle is not free. It runs slower in total than the rewrite would have. Velocity drops and stays down for as long as the migration runs, and features land later than they otherwise would. Not late. Planned later, which is a different thing, and the difference is what makes it defensible: the team is not slipping, it is shipping at a rate everyone agreed to in advance. The business still pays, every quarter, in a currency that never appears as a line item.

And neither path could be priced before choosing one. The numbers that would have said which was cheaper only existed afterwards. So I took the option that was easier to defend and did not have to be justified a second time. I am not certain that is the same as the option that was cheapest.

What I am certain of is the shape of the work, because that part is not a judgement call.

Pick one seam, a capability the old system owns that you can define cleanly at its edges. Move it out, route traffic to the new home, delete the old copy. Then the next one. The system shrinks from the outside in, and at every point you have a working product and a way back.

Three rules, and breaking one puts you back in a rewrite wearing different clothes. Start at a real seam rather than a convenient one, or you spend the migration inventing coordination the domain never needed. Make every step shippable, and if a stage cannot go to production alone and stay there, it is too big. And delete the old one before starting the next, or you are not migrating, you are accumulating, and in eighteen months you have two implementations of everything.

Mismatch is a thing you built that outgrew its fit. It was right, then the ground moved, and the failure is only in refusing to notice.

The last shape is stranger, and in a way the opposite. Not a thing you built that stopped fitting. A thing you keep almost building, over and over, that costs you something every time, and that should have been written down years ago as the thing you do not do.

That is where I go next.

Cases in this series are composites. The patterns are real, the companies are not.

The full Core and Bloat™ method, four boxes and all, sits at dirkbauer.com/core-and-bloat.html.

The question arrives as a hiring question. Do we build this capability in-house, or outsource it?

It gets argued as a cost question, which is why it rarely resolves. Someone runs salaries against day rates, someone else counters with recruiting time and ramp-up, and the spreadsheet declares a winner nobody quite believes.

Cost is not the deciding factor. Two other questions are.

Is this Core to what we do? Not "is it important." Everything on the roadmap is important. Core means the thing you are differentiated on, the thing customers would notice if it got worse.

Does it keep adding value, or is it a one-off? A capability that compounds, that gets better with every iteration and every bit of accumulated context, is a different animal from work that gets done once and is then done.

Core and compounding, build it in-house. Every hour an external team spends learning your domain is value that walks out when the contract ends. One-off and low-maintenance, hire it out. You do not need to own the knowledge of something you will do once.

The way I think about it is the excavator. Digging one hole this month and never again, you rent the machine and the person who drives it. Digging every day forever, renting is the expensive option dressed as the cheap one, and you should own the machine and get good at digging.

Here is why this note sits next to Platform Mismatch. The answer is not permanent.

A build-or-buy call is made at a scale, for a trajectory, and both of those move. The thing you outsourced at fifteen people because it was peripheral can become the thing you are differentiated on at eighty, and now the knowledge that makes you special sits in a vendor's team and leaves when the contract does. The thing you built in-house because it felt Core can turn out to be a commodity three companies now sell better than you build it.

Neither was a bad original decision. They are the same shape as the monolith at fifty engineers. Correct then, wrong now, quiet about it the whole way, because nothing broke.

So re-sort it when the scale has changed enough that the old answer deserves a fresh look. Otherwise last year's right call becomes this year's mismatch, and you find out from the workarounds.