When to Choose Boring Tech

Boring Tech Decision

The most valuable technology decision I ever made was choosing boring.

In 2005, when we were building Conductor, the hot technologies were Rails, early-stage NoSQL experiments, and various bleeding-edge frameworks. We chose ASP.NET, SQL Server, and message queues. Boring. Established. Unremarkable.

Twenty years later, that boring stack is still running. Still processing $100M+ annually. Still at 99.9% uptime. The exciting technologies from 2005? Most are deprecated, abandoned, or on their third major rewrite.

Boring tech isn't laziness. It's a strategy. Here's how to know when to use it.

The Decision Matrix

Before choosing any technology, run it through these questions:

1. Regulated or contractual uptime?

If you owe SLAs (Service Level Agreements) to customers, or regulators audit your systems, pick boring. You need predictability more than novelty.

Healthcare? Boring tech. Financial services? Boring tech. Any system where downtime means regulatory scrutiny, contract penalties, or people getting hurt? Boring tech.

2. Team familiarity?

If your team already knows the technology, use it. Ramp-up time is an invisible tax that compounds.

A team that's productive on Day 1 ships value on Day 1. A team learning a new framework ships bugs and confusion for months. The new framework would have to be dramatically better to overcome that productivity hit—and it rarely is.

3. Operational maturity?

Does the technology have battle-tested tooling for the stuff you'll actually need?

Monitoring that someone has used in production at scale
Backup and restore procedures that are documented and tested
Upgrade paths that don't require rewrites
Error messages that Google returns useful results for

If the answer is "not really, but it's improving fast," that's exciting for a side project. It's terrifying for a production system.

4. Ecosystem stability?

Are the libraries and dependencies you need:

Maintained by people who will still be maintaining them in five years?
Boring themselves, with predictable release cycles?
Not dependent on a single maintainer with commit access?

A language can be mature while its ecosystem is chaos. Check the dependencies, not just the core technology.

5. Replaceability?

If you might need to swap vendors, migrate hosting, or integrate with enterprise systems, stick to standards.

Exotic choices create lock-in. That lock-in feels fine when things are working. It becomes a nightmare when you need to change and can't.

The rule:

If you answer "yes" to three or more of these questions, choose boring. The opportunity cost of exciting tech is rarely worth the risks.

What Boring Looks Like

Boring isn't old. It's mature. Here's what I mean:

Databases:

Boring: PostgreSQL, SQL Server, MySQL—databases with well-known replication, backup stories, and a decade of production experience at scale
Not boring: The latest distributed database that promises infinite scale but has three blog posts about production deployments

Languages:

Boring: TypeScript, C#, Java, Python—ecosystems with debuggers, profilers, hiring pools, and more Stack Overflow answers than you'll ever need
Not boring: The language that's "like X but better" with 47 GitHub stars and one core maintainer

Frameworks:

Boring: Next.js, ASP.NET, Spring, Django—stable release cadences, corporate backing (or large community investment), and thousands of production deployments
Not boring: The framework that's "so much faster" but requires you to write your own auth, your own ORM, and your own everything else

Infrastructure:

Boring: Managed services where possible. Where self-hosting is necessary, well-known distributions with LTS (Long-Term Support) kernels
Not boring: The container orchestration system that's "simpler than Kubernetes" but has documentation written entirely by its creator

When Not to Choose Boring

Boring isn't always the answer. There are legitimate cases for exciting technology:

Early R&D where iteration speed matters more than stability:

If you're exploring whether something is even possible, use whatever gets you there fastest. The cost of the wrong technology choice is low when you might throw the whole thing away anyway.

But: isolate the exploration. Don't let R&D technology choices leak into production systems.

Edge constraints that legacy stacks can't meet:

New hardware, extreme latency requirements, novel computation patterns—sometimes the boring solution simply can't do what you need.

But: verify the constraint is real. Most systems don't actually need sub-millisecond latency or infinite horizontal scale. The constraint should be measured, not assumed.

Differentiated technology as a competitive advantage:

If your value proposition depends on a novel algorithm, proprietary approach, or cutting-edge technique, the technology stack may need to support it.

But: even then, isolate novelty. Put the innovative piece behind an adapter. Keep the rest of the system boring.

Examples from My Systems

Conductor (credentialing platform):

Stack: ASP.NET + SQL Server + message queues
Verdict: Boring
Result: 20 years, 99.9% uptime, zero security breaches, sold for a multiple that reflected the stability

The technology was unremarkable. The business outcome was remarkable. Those two things are connected.

DecisionForge (AI debate engine):

Novel piece: Multi-model orchestration, debate scoring, synthesis logic
Infrastructure: TypeScript/Next.js frontend, standard message queues, boring observability tools
Verdict: Novel orchestration, boring infrastructure

The AI logic is genuinely innovative. The infrastructure holding it up is not. The innovative part sits behind adapters, so we can swap models, change providers, and adjust without touching the plumbing.

Integrations (15+ external systems):

Pattern: Adapters with idempotency keys and versioned contracts
Verdict: Boring by design

Every integration uses the same boring pattern: contract, adapter, quarantine, circuit breaker. When partners change (and they always change), we change one adapter. The boring pattern made that manageable.

Costs You Avoid with Boring

Hiring cost:

Boring tech has bigger talent pools. You're not competing for the 47 engineers who know Obscure Framework X. You're hiring from the thousands who know TypeScript or Python or Java.

Recruiting takes weeks instead of months. Candidates don't need convincing that the tech is worth learning. Onboarding is faster because someone on the team has seen this before.

Ops cost:

Boring tech has better runbooks. When something breaks at 3 a.m., you're not the first person to experience the error. Someone has written about it. Someone has fixed it. The solution is on Stack Overflow.

Upgrades are predictable. Security patches exist and are maintained. The on-call rotation is manageable because problems have known solutions.

Compliance cost:

Auditors recognize boring stacks. They've seen PostgreSQL before. They know what SQL Server's security model looks like. They're not asking you to explain why your custom database is actually secure.

You spend time demonstrating compliance, not educating auditors about your technology choices.

Rewrite cost:

Boring tech rarely forces rewrites. The upgrade path exists. The migration documentation is written. You probably never do the "big rewrite"—you just keep incrementally upgrading.

The teams that chose exciting tech in 2015? Many of them are on their third framework. Each rewrite cost 6-18 months of productivity. We never rewrote. We just kept shipping.

How to Evaluate a "Boring" Stack

Score each dimension 1-5:

Maturity (1-5):

How long has it been used in production at scale? Are there documented case studies from companies larger than yours? Are upgrade paths clear and tested?

Tooling (1-5):

Are monitoring, backup, and deployment tools battle-tested? Are they boring too? (Don't pair a boring database with an experimental deployment tool.)

Talent (1-5):

Can you hire or contract expertise easily? Do you already have it on the team? Can someone ramp up in weeks, not months?

Compliance (1-5):

Does the stack help with audits (built-in logging, RBAC, encryption) or fight you? Will auditors recognize it?

Ecosystem (1-5):

Are libraries maintained and predictable, or a patchwork of abandonware? Are dependencies updated regularly? Are security patches available promptly?

If the average is 4+, you're in "safe to bet" territory. Below that, investigate the weak dimensions carefully.

Where to Allow Novelty

Exciting technology isn't banned. It's isolated.

Edges, not core:

Put innovation at the edges—analytics, recommendation engines, specific algorithms—behind adapters. Keep core transaction flows boring.

Your recommendation engine can use the latest ML framework. Your payment processing should use proven, audited libraries.

Isolated pilots:

Run new tech in a sandbox with a feature flag. Let specific tenants opt in. Gather data before committing.

If it works, expand. If it doesn't, kill it without touching the rest of the system.

Exit plan required:

If you can't describe how to roll back or replace the novelty, don't ship it to core paths. Innovation without an exit strategy is gambling.

How to Sell Boring Internally

"We should use boring tech" sounds like fear. Here's how to frame it productively:

Frame as risk reduction and time-to-value:

"Choosing [boring option] reduces our time-to-production by [X weeks] because the team already knows it, and it reduces our operational risk because the failure modes are documented."

Not: "We're scared of new things."

Show total cost:

Build a comparison that includes:

Hiring (how long to find people who know it?)
Ramp-up (how long until they're productive?)
Operations (what's the expected incident rate?)
Migration (if we need to change later, what's the cost?)
Compliance (what's the audit burden?)
Opportunity cost (what else could we ship while we're learning?)

Exciting tech often wins on feature comparison and loses on total cost.

Offer escape hatches:

"We'll isolate the innovative piece behind an adapter, so we can experiment without betting the company. If it works, we expand. If it doesn't, we haven't compromised the core."

This lets advocates of exciting tech pursue their case while limiting blast radius.

Context → Decision → Outcome → Metric

Context: Building a healthcare credentialing platform in 2005 that needed to run for decades, survive audits, and process $100M+ annually without drama.
Decision: Chose boring stack (ASP.NET, SQL Server, message queues) over trendy alternatives despite internal pressure to "modernize."
Outcome: 20 years of operation, zero rewrites, zero breaches, consistent upgrades without major migrations.
Metric: 99.9% uptime. Zero forced technology migrations. Compliance passed on first attempt every audit. Sale valuation reflected the stability premium.

Anecdote: The Framework That Ate a Company

In 2014, I consulted for a startup that had chosen an exciting new JavaScript framework—one of the hot ones that year. Their CTO was enthusiastic. The early velocity was impressive.

By 2016, the framework's development had stalled. The core maintainer had moved on. Breaking changes kept shipping with inadequate migration guides. The company had 200,000 lines of code built on a foundation that was slowly crumbling.

They spent 18 months on a rewrite to a boring framework. During that rewrite:

Zero new features shipped
Three engineers quit from frustration
Two major customers churned, citing lack of progress
Competitors gained ground

The rewrite cost them roughly $2.5M in engineering time and opportunity cost. The original technology choice, made to save a few weeks of initial development, ended up costing years.

When they finally finished the rewrite, their CTO—now humbled—said: "Next time, we're picking the boring option and keeping it boring."

They did. They're still in business. The competitors who kept chasing exciting tech? Two of the three are gone.

Mini Checklist: Boring Tech Decision

[ ] Answered "yes" to 3+ questions in the decision matrix
[ ] Technology has 5+ years of production use at scale
[ ] Hiring pool is large enough to staff without extraordinary effort
[ ] Tooling for monitoring, backup, and upgrade is mature
[ ] Compliance auditors will recognize the stack
[ ] Library ecosystem is maintained by multiple contributors
[ ] Novelty is isolated behind adapters with exit plans
[ ] Total cost comparison (not just feature comparison) favors boring
[ ] Team is aligned that boring is a strategy, not fear