Why I Chose Boring Technology (And It Saved Me Millions)

If you’re expecting a story about some exotic, bleeding-edge stack…
you’re going to be disappointed.

Conductor wasn’t built on the cool thing of the month.

It ran on what most developers would call boring:

• C# / ASP.NET
• SQL Server
• Windows Server + IIS
• A handful of Windows services and scheduled jobs
• Some SSRS-style reporting and batch jobs

No microservices.
No Kubernetes.
No NoSQL zoo.
No “serverless event mesh quantum blockchain cluster.”

And that “boring” decision is a big part of why the system:

• Stayed up for ~20 years
• Survived multiple waves of industry change
• Didn’t have to be completely rewritten every 3–5 years

That stability has a real dollar value.

---

1. What “Boring” Looked Like

The stack, roughly:

• Backend: C# on ASP.NET (Web Forms early on, then more modern patterns over time)
• Frontend: Server-rendered HTML, progressively enhanced; not a SPA circus
• Database: Microsoft SQL Server
• Hosting: Windows Server + IIS, in environments ops people knew how to manage
• Background work:
  • Windows services
  • Scheduled tasks
  • SQL Agent jobs
• Reporting:
  • SQL, stored procedures
  • Reporting tools the business side could understand

If you’re a modern dev, that sounds like:

“Enterprise oatmeal.”

Exactly.

---

2. The “Sexy” Alternatives I Didn’t Choose

Every era had its hype:

• Early on:
  • Ruby on Rails
  • PHP frameworks
• Later:
  • Node.js everywhere
  • NoSQL for everything
  • Early microservices pushes
• And always:
  • “Let’s rewrite this in [shiny thing]”

I didn’t pick them for Conductor because:

• They solved problems I didn’t actually have.
• The operational maturity wasn’t there yet (especially for healthcare).
• I didn’t want to be debugging the framework while also debugging my own system.

Could we have built Conductor on those stacks?
Probably.

Would it have survived 20 years with minimal rewrites in a regulated environment?
Much less likely.

---

3. The Decision Point: Why Boring Won

Timeline-wise, this started in the early–mid 2000s:

• Rails was exploding.
• “LAMP” was everywhere.
• A million ORMs and frameworks were promising 10x productivity.

I felt the same pressure everyone does:

• Developers wanted “modern.”
• Recruiters loved buzzwords.
• Conferences were full of:
  • “If you’re not building X like this, you’re dead.”

The logic I kept coming back to:

1. Ops people already know how to run Microsoft stack.

   • Hosting providers knew it.
   • Enterprise IT teams knew it.
   • Monitoring and backup practices were established.

2. The tooling was stable.

   • Mature debuggers
   • Profilers
   • DB tools
   • Good error logs and stack traces

3. The ecosystem was boring in the best way.

   • Fewer breaking changes
   • Long-term support lifecycles
   • Predictable upgrade paths

I didn’t need “clever.”
I needed predictable.

---

4. Why Each “Boring” Choice Was Right

ASP.NET + C#

• Strong tooling (Visual Studio, debugging, profiling)
• Solid type system saved us from whole categories of bugs
• Easy to hire:
  • Plenty of people with .NET experience
  • Transferable skills from other enterprise apps

SQL Server

• Rock-solid transactional database
• Great story for:
  • backups
  • point-in-time recovery
  • reporting
• Operators understood:
  • replication
  • clustering
  • performance tuning

Windows + IIS

• Every hosting/datacenter team had experience with it
• Tons of documentation and community knowledge
• Easy-to-understand deployment model:
  • Build
  • Drop binaries
  • Deploy with predictable behavior

Was it “hip”? No.

Did it stay alive and supportable year after year while:

• clinicians used it,
• states integrated with it,
• and real money flowed through it?

Yes.

---

5. “Saved Millions” – How That’s Not Just Rhetoric

I’m not going to pretend I have a neat spreadsheet that says:

“Here is the exact $X,XXX,XXX saved by boring tech.”

But you can back-of-the-envelope the savings from:

1. Not rewriting the core system every 5–7 years

   • A full rewrite of a platform like Conductor:
     • would easily be a high six- to low seven-figure project
     • multiplied over 20 years? You’re at multiple millions in avoidable cost.

2. Lower operational pain

   • Fewer:
     • “framework upgrade broke everything” episodes
     • surprise deprecations
   • That’s:
     • less downtime
     • fewer emergency patches
     • less time spent chasing ecosystem churn

3. Easier hiring and onboarding

   • No exotic stack tax
   • New hires could get productive faster
   • Less time “paying the novelty tax” on weird tooling and patterns

4. Vendor and ecosystem stability

   • Long support lifecycles
   • Fewer forced migrations
   • Tools that stuck around

All of that compounding over nearly two decades?

You’re absolutely in “millions saved” territory compared to a more fashionable, rewrite-happy path.

---

6. How the Stack Aged Over ~20 Years

Did we modernize parts of it? Sure.

• We refactored sections.
• Improved patterns internally.
• Tightened up hot paths as load grew.
• Reworked certain modules as needs changed.

But the key:

We never had to throw the whole thing away and start over
just because the tech went out of fashion.

The system stayed:

• Understandable
• Maintainable
• Deployable by sane humans

Some boring choices aged incredibly well:

• SQL Server: still here, still excellent at what it does.
• C#: matured nicely, the language got better without breaking everything.

Some parts aged less gracefully:

• Early ASP.NET WebForms-style patterns
• Certain UI pieces felt clunky as the web moved on

But those were refactor problems, not set-it-on-fire problems.

---

7. If I Were Building It Today (2024+)

Would I use the exact same stack? Not necessarily.

But the principles stay the same:

• Pick platforms with:
  • Long-term support
  • Strong tooling
  • A deep hiring pool
  • Proven success in your domain

Today that might mean:

• Still .NET for some things
• Or Java/Spring in certain environments
• Or a well-supported managed Postgres instead of “the trendiest new datastore”
• Containerization where it helps ops, not as religion
• A small number of services instead of a microservice explosion

The mistake isn’t “using new tech.”

The mistake is:

Anchoring your business to tech that hasn’t proven it can survive
the lifespan your customers expect from you.

---

8. The Hype Cycle vs. Real Systems

Developers who chase new frameworks aren’t evil.
They’re often:

• Curious
• Ambitious
• Tired of old cruft

There is a place for cutting-edge tech:

• Prototyping new products
• Internal tools with low blast radius
• Places where performance or capabilities genuinely require it

But using bleeding-edge everything in:

• Healthcare
• Finance
• State systems
• Any domain where failure is expensive and public

…is usually a bad trade.

Real systems live longer than hype cycles.

Your tech choices should respect that.

---

9. Hiring for Boring Tech

Was it harder or easier to hire?

Honestly:

• Easier to find solid, experienced engineers
• Harder to attract:
  • trend-chasers
  • people who want their resume to be a shrine to the latest toys

Which, for this context, was fine.

We needed people who:

• Took reliability seriously
• Cared about:
  • data integrity
  • auditability
  • long-term maintainability

You don’t need a 10x Rockstar Framework Influencer.

You need people who can keep a critical system healthy year after year.

---

10. Advice for Architects: When to Choose Boring

My framework is simple:

Choose boring when:

• The system:

  • touches money
  • touches health
  • runs operations
  • will live for 10+ years if things go well

• Failure is:

  • legally expensive
  • reputationally deadly
  • catastrophic for customers

• Your customers expect:

  • stability
  • audits
  • traceability

Take more risk when:

• It’s internal-only
• It’s genuinely experimental
• The blast radius of failure is small and contained

The question I always come back to:

“If this goes well, how long will this system live?”

If the answer is “decades,”
your stack has to be chosen like something that can survive decades.

That almost always means:

• More boring than Twitter thinks is acceptable
• More predictable than your inner hacker finds exciting

And if that saves you a few million in rewrites, outages, and churn?

Good. That’s the point.

---

Context → Decision → Outcome → Metric

• Context: Multi-tenant, regulated systems with money and health at stake; long lifespan expected; team needs reliability over novelty.
• Decision: Choose boring, mature stacks (ASP.NET/SQL Server, TypeScript/Next.js, managed infra) with adapters, observability, and strict change discipline; avoid resume-driven tech.
• Outcome: 20-year uptime, zero breaches, no full rewrites, and faster hiring of reliability-minded engineers.
• Metric: 99.9%+ uptime over decades; zero contract losses; avoided multi-million-dollar rewrites common in trend-chasing shops.

Anecdote: The “Modern Stack” Pitch

A vendor pitched a rewrite in a shiny new stack. We modeled the risk: learning curve, ecosystem churn, unknown tooling, and migration cost. Instead, we modernized in-place—added adapters, improved CI/CD, refreshed UI tech incrementally. Users saw faster pages and better UX; ops kept stability; the “modern” risk stayed contained. Boring won because it delivered value without roulette.

Mini Checklist: Deciding If Boring Is Right

• Will the system live 10+ years? Is failure expensive (money, compliance, safety)? If yes, default to boring.
• Do you have in-house expertise for the proposed stack? If yes, count it as a risk reducer.
• Can you hire for it easily? If no, reconsider.
• Is there a safe innovation lane (adapters, flags) so you can learn without betting the core? If not, build one before adopting novelty.