Choosing boring technology is not the same thing as falling behind, and the companies that confuse the two pay for it twice: once building the shiny thing, and again replacing it.
The best technical decisions come from two inputs: a precise understanding of the business requirements, and a deep knowledge of what technology can actually do. When you hold both, the right approach is usually obvious and often unexciting. When you hold only one, you get either timid under-building or expensive novelty. This is most of what I do as a fractional CTO: sit between the business problem and the full menu of technical options, and pick the option that solves the problem rather than the one that’s trending.
The Principle
Chase innovation only when it aligns with requirements and goals. That sentence sounds obvious and almost nobody follows it, because innovation carries social rewards inside a company (it looks like progress, it’s fun to build, it reads well in investor updates) that are completely disconnected from whether it serves a requirement.
The combination that produces genuinely bulletproof systems is lateral thinking and creativity applied across a full knowledge of the possibilities, old and new. Creativity without the knowledge produces naive choices. Knowledge without the creativity produces defensive, calcified ones. Together they produce decisions like “the 20-year-old relational database is the right answer here, configured in a way most teams never bother to learn,” which is both boring and nearly unbeatable.
Innovation for the sake of innovation is the path to destruction. Not stagnation, destruction: new frameworks carry migration costs, immature tooling, hiring constraints, and unknown failure modes, and a business that adopts them without a requirement pulling them in has volunteered for all four in exchange for nothing.
Pitfall: “We Need AI, Everyone Has AI”
The most common 2026 version of innovation-for-its-own-sake. The demand arrives as a technology (“we need AI”) rather than as a requirement, which is backwards.
The better version: understand when and where an LLM actually makes sense, and apply it to the specific cases where it does. LLMs are genuinely transformative for certain shapes of work: unstructured text in, structured judgment out, summarization, classification, extraction, drafting. They are expensive, slow and nondeterministic for problems that a query, a regex or a lookup table solves exactly. A product with one well-chosen LLM feature that works every time beats a product wrapped in AI branding that’s wrong 8% of the time, and the 8% is what your customers remember.
The question I ask is never “where can we add AI?” It’s “which of our actual problems have the shape that LLMs solve?” Sometimes the honest answer is several. Sometimes it’s none.
Pitfall: “Our Stack Is Slow and Outdated, We Need the Latest Framework”
Slowness gets blamed on age, and age gets cured with novelty. But slowness almost always has a specific, findable, boring cause.
The better version of this conversation: our system is slow because the MySQL server is missing indexes on the queries that matter, carries legacy blob values inside hot tables, and uses unoptimized column types. Upgrading MySQL and fixing the schema solves most of the problem for a fraction of the investment, with none of the rewrite risk.
I’ve had exactly this engagement more than once, and the pattern repeats: the team was sure the framework was the problem, nobody had run an EXPLAIN on the five slowest queries. A rewrite would have shipped eighteen months later, slower, on top of the same unindexed database.
Pitfall: “Rip It All Out and Reinvent”
The most expensive sentence in software: our current tech isn’t working, it’s slowing us down, we need to rebuild on the latest and greatest.
Before agreeing, ask three questions. What specifically isn’t working? Why are those things slow? What is the true root cause? Pursue the answers past the first response, because the first response is usually a feeling, not a diagnosis. Quite often the root cause turns out to be wrong systems decisions and broken processes (no staging environment, no review discipline, unowned deployments, undocumented integrations) sitting on top of a perfectly serviceable stack. Rebuild on the hottest framework available and keep the same decisions and processes, and you will faithfully reproduce every problem you paid to escape, minus the decade of bug fixes the old system had accumulated.
Rewrites are sometimes right. They’re right when the diagnosis says so: when the actual root cause lives so deep in the architecture that fixing it costs more than replacing it. That conclusion should take weeks of investigation to reach, not one frustrated meeting.
What This Looks Like in Practice
The discipline is a sequence, and it never changes:
- Requirements first, stated as business outcomes, not technologies.
- Diagnosis before prescription: measure, profile, read the queries, find the root cause.
- Survey the full option space, including the boring options, honestly.
- Pick the cheapest option that fully solves the problem, and spend the savings on the things that actually differentiate the business.
- Adopt new technology eagerly when a requirement pulls it in, and never when fashion pushes it.
This is the judgment startups are actually buying when they bring in senior technical leadership: not enthusiasm for new technology and not reflexive conservatism, but the experience to know which problems deserve which tools. It’s the core of my fractional CTO and product lead work: strategic technical decisions made by someone who has seen enough systems succeed and fail to know that boring is a feature, and who then stays to build the solution rather than leaving a slide deck behind.