Boring technology is the right default for systems that must run for a decade

July 1, 2026 · 5 min read · HQT

Most of the software an agency puts into service this year will still be running when the people who selected it have moved on. Permitting and licensing systems, case management, utility billing, and records applications survive several budget cycles, more than one administration, and a good deal of staff turnover. The useful question about a technology choice is therefore not which option is best today. It is which option will still be supportable, staffable, and patchable a decade from now.

We use the phrase boring technology to mean something specific. A boring tool has a long public track record, more than one source of support, a documented upgrade path, and enough working practitioners that hiring is realistic. Boring is not a synonym for old or bad. It is a statement about how a choice behaves over time.

Five questions about year ten

Before adding a component to a design, we ask about the years after launch, not about the demo.

1. Who applies security patches, and will patches still be published?
2. Can the agency hire someone who already knows this, or is the labor pool one firm deep?
3. Is there a documented upgrade path between major versions, or does upgrading mean a rewrite?
4. If the vendor or project stops, what is the exit, and can the data be exported in a documented format?
5. Can someone outside the original team understand it well enough to write a runbook?

A novel tool can look excellent against a feature checklist and fail all five. The years after go-live are when a system is maintained rather than built, and that is when the answers matter.

What novelty costs later

The cost of an unusual choice rarely appears during the build. It arrives afterward, in small pieces.

• Operational answers exist only in a chat channel or a single blog post, so routine problems become research projects.
• Hardening guidance and audit evidence do not exist yet, so security review turns into an argument from first principles.
• The upgrade path is undocumented, so the system stays at the version it launched with.
• One engineer understood the unusual part, and that engineer leaves.

None of these is dramatic on its own. Together they produce a system that works and that nobody wants to touch.

Maturity has operational consequences

The components we reach for first have the deepest public record: relational databases, standard HTTP interfaces, container images, scheduled jobs, object storage, and server-rendered pages with only as much client-side code as the interface needs.

Widely used platforms tend to publish support lifecycles, which lets an agency plan end-of-support work into a budget cycle instead of discovering it during an audit. They tend to be covered by published hardening benchmarks, such as the CIS Benchmarks and, in defense contexts, DISA Security Technical Implementation Guides, which gives a security review a shared reference instead of a debate. They tend to have accessible, well-tested interface patterns, which matters because public sector digital services carry accessibility obligations: Section 508 for federal agencies, and Title II of the Americans with Disabilities Act for state and local governments, with the Web Content Accessibility Guidelines as the technical reference in both cases. Newer tools acquire these things eventually. A system going into service now cannot wait for eventually.

Spend novelty deliberately

This is an argument for a budget, not a ban. On our internal systems and reference builds we hold ourselves to a small number of genuinely new components per project, each chosen because the conventional option could not do the job, and we write down the reason.

The other half of that rule matters more. Keep the new thing behind a stable interface, and keep it out of the path of the data of record. A novel search index sitting in front of a conventional database can be pulled out without touching the records. A novel database holding the only copy of the permit history cannot be pulled out without a migration project.

We also keep a short written list of default choices covering runtimes, data stores, deployment pattern, and identity integration. Departing from the list is allowed and requires a decision record naming the alternative and the tradeoff accepted. Our systems then resemble each other, so anyone on the team can operate any of them, and the list changes on evidence rather than on interest.

Writing durability into a solicitation

Requirements can ask for longevity without naming a product.

• Ask for the published support lifecycle and end-of-support dates of every proposed component.
• Ask how many independent firms could support the proposed stack, and how the offeror determined that.
• Require standards-based interfaces and a documented, tested export of all data.
• Require infrastructure definitions, runbooks, and build instructions as deliverables, not only a running system.
• Ask what the agency does if the product is discontinued, and score the answer.

Where to start

Pick one system you expect to keep for a decade and run the five questions against it. Where an answer is uncomfortable, you have found maintenance work to schedule rather than an outage to discover. For the next procurement, put the durability questions into the evaluation criteria, weighted heavily enough to change a score. Novelty is worth paying for in the places where it solves a problem the conventional option cannot.