Choosing boring technology on purpose
There is a strong pull in software towards the new. A framework released last month, a database everyone is talking about this quarter, a pattern that is having its moment. It is genuinely exciting, and occasionally the new thing really is better. But for most client work, we deliberately reach for the boring option — the proven, well-understood tool that thousands of teams already run in production. Here is why that is a feature, not a lack of ambition.
”Boring” means the problems are already solved
When you pick a technology that has been around for years, you inherit an enormous amount of free work. The common bugs have been found and fixed. The security edge cases are documented. The performance traps are well known. When something goes wrong at 2am, the error message you paste into a search engine returns a real answer from someone who hit it before you — not an empty page.
A brand-new tool has none of that. You are not just the user; you are also the beta tester, the bug reporter, and the person who discovers the sharp edges the hard way. That can be worth it for a research project. It is rarely worth it for a business that simply needs its software to work.
Innovation tokens are limited — spend them where they count
A useful way to think about this: every project has a small number of “innovation tokens.” Each genuinely novel technology you adopt spends one, because it adds risk and unknowns. Spend them all on infrastructure — a new language, a new database, a new framework, all at once — and you have no tokens left for the part that actually matters: solving your customer’s problem in a way nobody else has.
So we spend our innovation budget on the problem, not the plumbing. The stack should be the dependable, forgettable foundation. The interesting, differentiated work belongs in the product, where it benefits the user — not in a database nobody has run in anger.
Boring technology ages well
This connects directly to longevity. Proven tools tend to have stable upgrade paths, long support windows, and large communities that keep them maintained for years. A trendy choice can be abandoned the moment its moment passes, leaving you stranded on an unsupported dependency with no clear way forward. We have seen plenty of “cutting-edge” stacks become maintenance liabilities within a couple of years, while the unfashionable choices kept running quietly the whole time.
The same logic is why we put long-lived projects on platforms we control and understand. GOBC Real Estate School, for example, runs on CourseDesk, our own learning platform — a system we maintain as a product rather than a one-off build, precisely so that improvements and fixes keep flowing to it for years. Stability there is not an accident; it is the whole point.
When the new thing is the right thing
None of this is an argument against ever adopting new technology. New tools earn their place all the time, and standing still is its own kind of risk. The discipline is in the why: we adopt something new when it solves a real problem the boring option cannot, when it is mature enough to trust with someone else’s business, and when the benefit clearly outweighs the cost of being early. That is a deliberate decision with a reason behind it — not a reflex to use whatever is trending.
The quiet payoff
The reward for choosing boring technology is that you rarely notice it. The site keeps serving. The upgrades go smoothly. The team can find answers when they need them. Years after launch, the software is still understandable by whoever picks it up next. None of that makes for an exciting launch announcement — and that is exactly why it is worth so much.
If you are commissioning something that needs to be running and maintainable years from now, the least glamorous question is also the most important: will anyone still understand and support this stack in five years? We build so the answer is always yes.