Engineers are curious people, which is mostly why they are good at the job. It is also why so many production systems contain one component that exists because somebody wanted to try it. Two years later, that component is the reason nobody can deploy on a Thursday.
We are not against new technology. We build on tools that were experimental five years ago. But we are deliberate about where novelty is allowed, because every unfamiliar choice draws down the same limited budget: the team's ability to reason about the system at three in the morning.
Spend novelty where it differentiates
A useful rule: a project gets one or two interesting choices, and they should be in the part of the system that makes the product distinctive. Everything else should be the option with the most documentation, the largest hiring pool, and the fewest surprises.
For most of our clients this means PostgreSQL rather than a specialised datastore, a boring queue rather than a bespoke event mesh, and a monolith with clean internal boundaries rather than eleven services maintained by four people. The interesting part is then free to be genuinely interesting: the domain model, the scheduling algorithm, the AI evaluation harness.
Every new technology in a system is a second thing to learn, patch, monitor, hire for, and eventually migrate off.
The questions we ask before adopting anything
- What does this replace, and what specifically breaks if we do not adopt it?
- Who on the client's team will operate it after handover, and what will they need to learn?
- What is the escape route if the project is abandoned upstream in two years?
- Can we observe it with the tooling we already run, or does it need its own?
- Is the problem it solves one we actually have at our scale, or one we have read about?
That last question retires more candidate technologies than the others combined. A great deal of infrastructure exists to solve problems that appear at a scale most businesses will never reach, and adopting it early means paying the operational cost without the benefit.
Boring is not the same as old
This is where the argument gets misread. TypeScript everywhere, strict mode on, is a boring choice now, and it eliminates an entire category of production incident. Infrastructure as code is boring. Automated tests in a pipeline are boring. Structured logs with correlation ids are boring. None of these are old, and all of them are the opposite of exciting to demonstrate.
The mark of a boring stack is not its age. It is that failures are diagnosed rather than investigated, and that a competent engineer who joins in month nine can be productive in a fortnight.
What this buys the client
A platform we handed over last year is still running on the architecture we deployed, maintained by the client's own two-person team, with no calls to us for eleven months. That is the outcome we are optimising for. Not the most sophisticated system we could build, but the most sophisticated system somebody else can confidently own.
If your engineering partner is excited about the technology and vague about who operates it after they leave, that is worth a conversation.
About the author
Bonolo Mathabela
Bonolo co-founded Bonang Technologies to prove a specific point: that a small, senior team with clear standards ships better software than a large one with none. As COO they own how the studio runs: how work is estimated, how it is staffed and reviewed, and what is allowed to reach production.
