It Should Have Been One Boring App
We recently took on a rescue project. It is six years old, it serves one business, and it runs on eleven microservices plus two separate frontend applications.
It should probably run on one boring app.
The company that built it walked away earlier this year. No drama, no falling out — they are a product company, and building for clients was never their real business. That sentence is the whole story, but the details are worth telling, because the pattern is common and almost nobody warns you about it.
Why eleven?
The original developers had built their own Backend-as-a-Service platform. So when this client arrived with what is, at heart, a straightforward business application, the project got built on that platform — split into eleven services, with two frontend apps on top.
Not because the problem demanded it. Because that is what they had in their hands.
It is important to say this plainly: this is not incompetence. It is incentives. A product company doing service work on the side will reach for its own product every time. From their side it is entirely rational — they know it deeply, it exercises their platform, and it makes the client more dependent on it. It just is not rational for the client.
What over-engineering actually feels like
"Hard to maintain" is an abstraction until you are inside it. Concretely, it looks like this: a small feature touches four services, so a small feature is never small. A bug hunt crosses service boundaries, so finding a bug costs more than fixing it. Every service is one more thing to deploy, monitor, and keep secure. And because the architecture only made sense to the people who built the platform underneath it, their departure took most of the system's understanding with them.
None of this shows up in a demo. The system worked on launch day. Complexity does not send an invoice up front — it collects quietly, every month, for years.
The budget trap
Here is the part that stings most. A proper rebuild — the one boring app — costs more than the company can spend this year. So this year's budget will mostly go to patching the current system instead. Next year, the same. Every patch is money invested in the thing that should be replaced, and the rebuild never gets closer.
The real cost of the wrong technical partner is not the invoice. It is the years of optionality it quietly eats.
How to choose a development partner
The client could not have known to ask the right questions six years ago. Nobody tells you until it is expensive. So here they are — the three questions we would want every non-technical founder to ask before signing with a development partner.
1. Is building for clients their core business — or a sideline to their product? A services-first firm lives or dies by the long-term health of client projects. A product company doing services on the side has a different center of gravity, and when the sideline stops being worth it, they leave. Ask what percentage of their revenue is client work, and how long their oldest client has been with them.
2. Will they choose the technology that fits your problem, or the technology they own? If a partner has a platform, a framework, or a "proprietary accelerator," ask what they build when it does not fit — and listen for whether the answer names real alternatives. The right tool for most business applications is unglamorous, widely known, and replaceable. That is a feature.
3. If they disappear tomorrow, can a normal team pick up what they built? This is the question that would have saved our client. Boring, mainstream technology means thousands of developers can take over. A bespoke eleven-service platform means the only people who can maintain it are the people who just left. Ask them directly: who else could run this?
Boring is the point
We are untangling the system now, and it will be fine. But it should never have needed rescuing — and the fix, when it comes, will not be clever. It will be one well-built, well-tested, thoroughly ordinary application that any competent team can understand, extend, and keep alive for the next decade.
If you have inherited something like this — from a vanished agency, a departed developer, or a partner whose priorities moved on — the first step is a cheap one: an audit, not a rebuild. Know exactly what you have and what it costs to keep, before spending another year patching it. Get in touch and we will take a look.