Operational software is the kind a business leans on daily: dispatching, compliance, billing, bookings. When it stops, work stops. For that category we choose technology the way you would choose a delivery van, and the market keeps trying to sell everyone a concept car. This article explains what "boring" means to us, why we bill for it with a straight face, and where we happily spend novelty anyway.
Boring is a measurable property
Boring does not mean old, and it certainly does not mean bad. It means the technology's failure modes are known. A tool that has run in production across thousands of companies for a decade has had its surprises found, written up, and answered on the internet. When it misbehaves at 2am, the fix is a search away, because someone in Ohio hit the same wall in 2019 and blogged about it. A framework released eight months ago may be genuinely better on paper, and its 2am problems are still unpublished. You would be the one writing that blog post, at 2am, at your own expense.
The three tests we apply
Any technology that wants into an operational build passes three tests. The hiring test: can a competent developer be found for this in two years, at normal rates, without a safari? The debugging test: when it fails, do mature tools exist to see inside it, and does a decade of answered questions exist behind it? And the exit test: if this choice turns out wrong, what does leaving cost? Choices that fail the exit test are how systems become hostages. Passing all three does not make a technology exciting. It makes it employable.
The innovation budget
We borrowed an idea that circulates among engineers who run things: every project gets a small innovation budget, and it is spent where the product genuinely differentiates. If the product's edge is pricing intelligence, spend novelty there, on the models and data work that make it smarter than the competition, and keep the login page profoundly unremarkable. A fleet-compliance platform we operate processes GPS data in real time, every minute of every day. The processing logic is where the cleverness lives. The stack under it is the most predictable arrangement we could assemble, because a clever engine on wobbly rails is just a faster way to crash.
What boring buys the person paying
Here's the honest picture of what you get for accepting unfashionable choices. Estimates hold better, because known tools have known costs. Bugs get fixed in hours instead of days, because the answers exist. Any future team can take over, which keeps you free to leave us, and keeps us honest for exactly that reason. And the product survives trends. Software built on 2016's sensible defaults still runs quietly today. Software built on 2016's exciting defaults has mostly been rewritten, and somebody paid for that twice.
When we get talked out of it
So to confirm: this is a default, and defaults have exceptions. Sometimes a newer tool is the honest choice, because it removes a whole category of work or fits a constraint nothing mature can meet. When that happens we say so, in writing, with the risk named next to the benefit, and the decision documented so that in two years nobody has to reverse-engineer why. What we will not do is spend your innovation budget on our own entertainment. Engineers love new toys. We are engineers. That is exactly why the rule is written down.
If a proposal on your desk lists technologies you have never heard of and cannot hire for, ask the three tests out loud and watch what happens. And if you want a second opinion on a stack, ours or anyone's, the intro call is 30 minutes with Alexandru and costs nothing. Bring the proposal. We will tell you which parts are the delivery van and which parts are the concept car.