Sizing a system for the team that inherits it

01The situation

A founder came to us with an architecture diagram somebody else had drawn. Service mesh, six microservices, a managed Kubernetes cluster, an event bus. It was a good diagram. It was internally consistent. It was for a product with no users yet and one engineer who was also the CTO and also doing sales.

Nobody had lied to them. Every box on that diagram is a reasonable thing to want. The question nobody had asked was who would be awake at 3am when the event bus backed up.

02What we found

Ambitious infrastructure is rarely chosen for bad reasons. It is chosen because it is what a bigger version of the company would need, and planning for the bigger version feels responsible.

The cost is not the cloud bill, though that is real. The cost is that every one of those boxes is a thing somebody has to understand, upgrade, patch, monitor and eventually debug under pressure. Six boxes and one engineer is not a system, it is a queue.

03What we did

Before we choose anything, we ask one question and we write the answer at the top of the design: who is running this in eighteen months, and how many of them are there?

Everything follows from that number. If the answer is “one engineer, part time”, the design gets boring on purpose. Managed database, managed application runtime, one deployable unit, one dashboard, one place logs go. If the answer is “three engineers with a platform background”, the answer changes, and it should.

For that founder we shipped a single application on a managed runtime, with a managed database and a queue for the two things that genuinely needed one. Two moving parts. The architecture diagram fits on a postcard, which is the point: they can hold the whole thing in their head.

The question is not how far it scales. It is who is awake when it does not.

04What changed

They kept shipping. That is the whole outcome and it is the only one that mattered at that stage. Nobody spent a Thursday debugging a networking policy.

We also wrote down what would have to become true for each of the boxes we did not build. Not “never use Kubernetes”, but “when you have three engineers and more than one deployable thing, here is the conversation to have again”. The decision is documented with its own expiry conditions.

05What we would do differently

We were too gentle about it at first. We presented the small design as one option beside the large one, which made it look like the cheap choice rather than the correct one, and the conversation went in circles for a fortnight.

Now we lead with the operating question and let the design fall out of it. It is a much shorter meeting, and it puts the decision where it belongs: not in a comparison of technologies, but in an honest count of the people who will be holding the pager.