Two Tills and a Back Room: Sizing Software for the Team You've Got

Walk into a good corner shop and you can read the whole operation in about ten seconds. There's a counter, a till, a back room with just enough stock, and someone behind the counter who knows what the regulars buy. Nobody has installed a conveyor belt. Nobody is running three warehouses in different regions. The shop works because it is sized to the job.

Software teams are often less sensible. A product team of six, serving a few thousand users, will somehow end up with a service mesh, an event bus, and a deployment pipeline that needs its own on-call rota. The architecture looks impressive on a diagram. It also makes every small change feel like moving a fridge through a narrow hallway.

This isn't an argument against complexity. It's an argument for earning it. The corner shop doesn't refuse to buy a second till when the queue reaches the door. It just doesn't buy one before that happens.

The shop floor test

Before adding a new piece of infrastructure, ask a blunt question: who walks in tomorrow and benefits?

If the answer is 'the platform team, eventually' or 'a future scaling event we haven't seen', treat that as a hypothesis rather than a plan. Write it down. Give it a date to be reviewed. Then carry on with the simpler thing.

A useful version of this test is to name the actual person or team affected. Not 'users' in the abstract. A specific support colleague who is currently reconciling invoices by hand. A specific developer who is waiting twenty minutes for a test suite. A specific customer in Leeds who cannot complete checkout on a train. If you can't name them, the complexity is probably for you, not for them.

What you probably need first

For most small UK product teams, the boring stack is still the right stack: one deployable application, one relational database, and one queue for the handful of jobs that genuinely need to happen later.

That is not a philosophical position. It's an observation about where the pain usually is. A monolith is easy to reason about when you have one team. A single database gives you transactions without a distributed systems essay. One queue handles emails, exports, and image resizing without turning every request into a saga.

The trick is to keep the monolith honest. A modular monolith — clear boundaries inside the codebase, no shared back doors between modules — gets you most of the organisational benefits of services without the network tax. You can still split later. You'll have a much better idea of where the seams belong because you'll have watched the code change for a year.

The checklist before you split

Here's a short set of questions worth keeping on the wall. They are deliberately unglamorous.

• Do you have more than one team deploying independently? If not, a service boundary is mostly a communication boundary you don't need yet.
• Is the database the actual bottleneck? Not 'might be one day'. Measured, this month, with a graph.
• Can you name the asynchronous work? If the answer is 'all of it, because events are cleaner', that is a design preference, not a requirement.
• Would a customer notice the difference? Faster checkout, fewer errors, a feature that wasn't possible before. If not, you're buying a forklift for a shop that sells newspapers.
• Can you support it on a quiet Friday? Every new moving part needs an owner, a dashboard, and a runbook. Count them before you add them.

None of these questions are anti-architecture. They are pro-context. The same team that shouldn't split its monolith today might be entirely right to split it next spring.

When the complexity is earned

The signals are usually concrete. You have two teams that genuinely need to release on different schedules, and the coordination cost has become the main source of delays. One part of the system has a wildly different load profile — a reporting job that hogs the database every Monday morning. You have a regulatory reason to isolate data, or a failure domain that must not take down the rest.

Those are real. They come with names, dates, and a cost you can point at. That is what earned complexity looks like. It arrives after the evidence, not before it.

There's also a cultural signal: the team has the operational maturity to run what it builds. If nobody wants to be on call for a new service, that is useful information. Don't ignore it.

Keep the counter clear

One of the quiet skills in small teams is protecting the public surface. The counter is where customers interact with you. Everything behind it should be arranged so the counter stays simple.

In software terms, that means a small number of clear interfaces, a predictable deployment, and an honest separation between what customers see and how the sausage is made. The moment internal implementation details start leaking into the product — internal service names in error messages, database IDs in URLs, admin tools that assume a particular topology — you've turned the back room into the shop floor.

Keep the counter clear. Let the back room be messy in a controlled way. Customers don't need to know where the stock is kept, only that it's there when they ask.

Know your regulars

Corner shops survive because they know their customers. Small product teams have the same advantage, and they should use it more deliberately.

Talk to the support team. Read the tickets. Watch a handful of sessions. Look at the actual numbers for the actual traffic you serve. It is astonishing how often a planned scaling project dissolves once someone checks the graph and finds that the peak is eleven requests per second on a Tuesday.

That doesn't mean you'll never grow. It means you'll grow with evidence. You'll add the second till when the queue reaches the door, not because a conference talk suggested it.

Sizing software well is not about settling for less. It's about spending your complexity budget where it buys something. For most teams, most of the time, that means a small, well-kept shop with a clear counter, a sensible back room, and a team that knows exactly who it is serving.