The best technical decisions come from two inputs:
- Requirements: a precise understanding of what the business actually needs
- Capabilities: deep knowledge of what technology can actually do, old and new
Hold both and the right approach is usually obvious and often unexciting. Hold only one and you get either timid under-building or expensive novelty. Sitting between those two inputs is most of what I do as a fractional CTO: pick the option that solves the problem, not the one that’s trending.
Requirements Before Technology
Innovation for the sake of innovation is the path to destruction.
A new framework or platform adopted without a requirement pulling it in volunteers the business for four costs in exchange for nothing:
- Migration cost to get there
- Immature tooling once you arrive
- A smaller hiring pool to maintain it
- Failure modes nobody has seen yet
The combination that produces bulletproof systems is lateral thinking applied across a full knowledge of the possibilities. Creativity without the knowledge produces naive choices. Knowledge without the creativity produces calcified ones. Together they produce decisions like “the 20-year-old relational database is the right answer, configured in a way most teams never bother to learn,” which is both boring and nearly unbeatable.
Three Common Pitfalls
| What gets said | What’s usually true | The boring fix |
|---|---|---|
| “We need AI, everyone has AI” | A technology is being requested instead of a requirement | Find the problems shaped like LLM problems; skip the rest |
| “Our stack is slow and outdated” | Slowness has a specific, findable, boring cause | Profile first; it’s usually the database, not the framework |
| “Rip it all out and rebuild” | Process and systems decisions are the root cause, not the stack | Diagnose for weeks before deciding; rewrite only when the diagnosis says so |
Pitfall 1: “We Need AI”
“We need AI. Everyone has AI.”
The most common 2026 version of innovation for its own sake: the demand arrives as a technology instead of a requirement, which is backwards.
The better version is knowing when and where an LLM actually makes sense, and applying it only there. The shapes LLMs genuinely transform:
- Unstructured text in, structured judgment out
- Summarization, classification, extraction
- Drafting that a human reviews
For problems a query, a regex or a lookup table solves exactly, an LLM is slower, costlier, and wrong some percentage of the time, and the wrong answers are what customers remember. The question is never “where can we add AI?” It’s “which of our actual problems have the shape AI solves?” Sometimes the honest answer is several. Sometimes it’s none.
Pitfall 2: “Our Stack Is Slow and Outdated”
“Our current stack is slow and outdated. We need the latest frameworks and languages.”
Slowness gets blamed on age, and age gets cured with novelty. But the diagnosis almost always comes back boring:
“Our system is slow because the MySQL server is missing indexes on the queries that matter, carries legacy blob values in hot tables, and uses unoptimized column types. Upgrading MySQL and fixing the schema solves most of it with minimal investment.”
I’ve had exactly this engagement more than once, and the pattern repeats: the team was certain the framework was the problem, and nobody had run an EXPLAIN on the five slowest queries. The rewrite would have shipped eighteen months later, slower, on top of the same unindexed database.
Pitfall 3: “Rip It All Out”
“Our current tech isn’t working and it’s slowing us down. We need to rip it all out and reinvent with the latest and greatest.”
The most expensive sentence in software. Before agreeing to it, three questions, pursued past the first answer, because the first answer is usually a feeling rather than a diagnosis:
- What specifically isn’t working?
- Why are those things slow?
- What is the true root cause?
Quite often the root cause is wrong systems decisions and broken processes sitting on top of a perfectly serviceable stack: no staging environment, no review discipline, unowned deployments, undocumented integrations. Rebuild on the hottest framework and keep those, and you faithfully reproduce every problem you paid to escape, minus the decade of bug fixes the old system had accumulated.
Rewrites are sometimes right: when the root cause lives so deep in the architecture that fixing it costs more than replacing it. That conclusion should take weeks of investigation, not one frustrated meeting.
The Decision Process
The sequence 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 what differentiates the business
- Adopt new tech when a requirement pulls it in, never when fashion pushes it
This judgment is what startups are actually buying in senior technical leadership: not enthusiasm for new technology, 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 decisions from someone who has seen enough systems succeed and fail to know boring is a feature, and who stays to build the solution rather than leaving a slide deck behind.
The same rule applies to the two areas clients ask me about most. For most web applications a proven framework like Laravel is still the right foundation, and as an AI consultant I start with the boring, measurable use cases before anything experimental.
Top comments (0)