The Boring Tech Stack: Why Non-Tech Founders Win

Photo by Barn Images on Unsplash

The case for a boring tech stack is strongest for exactly the people who feel least qualified to make the argument: non-technical founders. Boring technology — Postgres, a mainstream framework, a payment processor everyone uses — has failure modes that are already documented, already answered on the public internet, and already well represented in the training data of the AI assistant writing your code. Interesting technology has none of that. When you can read code fluently, novelty costs you time. When you can't, novelty costs you the ability to get unstuck at all. That asymmetry is the whole argument.

TL;DR

• "Boring" means well-understood, not bad. Its defining property is that the failure modes are known, not just the features.
• Dan McKinley's innovation-token model still holds: you get roughly three novel choices, and most founders overestimate their budget.
• For non-technical founders the stakes are higher, because an unusual stack degrades the quality of the help you can get — from search, from forums, and from your AI assistant.
• Boring tech comes with calendars. PostgreSQL publishes a five-year support window per major version, so your upgrade obligations are knowable years out.
• Spend your innovation tokens on the thing customers actually pay you for. Everything below that line should be the least-worst default.

What counts as boring technology?

Boring technology is technology whose capabilities and, more importantly, whose failure modes are already well understood. That definition comes from Dan McKinley's 2015 essay "Choose Boring Technology", which is still the clearest statement of the idea eleven years later, and it's worth being precise about because the word invites misreading.

McKinley is explicit that boring is not a synonym for bad. "There is technology out there that is both boring and bad," he writes. "You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough." His list at the time was MySQL, Postgres, PHP, Python, Memcached, Squid, and Cron. Update the names and the shape holds: the boring option is the one where somebody has already hit your problem, written it down, and moved on.

The mechanism he identifies is about knowledge, not maturity in the abstract. Every technology has known unknowns ("we don't know what happens when this database hits 100% CPU") and unknown unknowns ("it didn't even occur to us that writing stats would cause GC pauses"). Both sets are non-empty for tech that's decades old. But for new technology, the unknown-unknown set is much larger — and that's the set that ruins weekends, because by definition you can't plan for it.

The other half of the essay is the innovation-token model. Every company gets about three innovation tokens; the supply is fixed for a long while, and the general tendency is to overestimate the contents of your wallet. Choosing an unusual database spends one. Choosing an unusual runtime spends one. Choosing to write your own anything spends several.

What makes this a business argument rather than an aesthetic one is McKinley's framing of the job itself: your function is to map business problems onto a solution space that involves choices of software, and "the 'best' tool is the one that occupies the 'least worst' position for as many of your problems as possible." Best-tool-for-the-job thinking assumes tools are free to adopt. They aren't. Each one adds monitoring, testing, deployment, and cognitive overhead — and the long-term cost of keeping a system working reliably vastly exceeds any inconvenience you hit while building it.

That's the standard version of the argument, written by an engineer for engineers. The version that matters for this blog is different, and I think it's stronger.

Why boring matters more when you can't read the code

Here's the part McKinley didn't need to write in 2015: a non-technical founder's stack choice determines the quality of help available to them, and in 2026 most of that help comes from an AI assistant.

When Claude Code or Cursor writes code for you, it's drawing on patterns it has seen many times. Popular, long-lived technologies are densely represented — years of documentation, tutorials, Stack Overflow answers, GitHub repositories, and blog posts arguing about edge cases. Newer or niche technologies are thinly represented, and the model's output degrades in a specific and dangerous way: it stays confident.

This is the mechanism behind a failure I've written about before — AI assistants inventing plausible-looking APIs and file paths. The model isn't lying. It's interpolating from adjacent patterns because it doesn't have dense coverage of the actual thing. On a mainstream stack, that interpolation is usually right or obviously wrong. On an obscure library, it produces code that looks correct, uses method names that sound right, and fails at runtime with an error you can't interpret.

Then the second failure compounds it. You paste the error into a search engine and get nothing, because forty people have ever hit it. On Postgres you'd have found a decade-old mailing list thread from someone with your exact problem.

There's a third cost that's easy to miss. Boring technology usually has boring conventions, which means an AI assistant can guess correctly about things you never specified. Ask for a Postgres schema and you'll get sensible types, an index on the foreign key, and a created_at column, because that's what everyone does. Ask for the same in an unusual data store and you get whatever the model half-remembers.

None of this means new tools are off-limits. It means the cost of novelty is not evenly distributed. A senior engineer adopting a brand-new framework pays in reading time and debugging. A non-technical founder adopting the same framework pays by losing their primary means of making progress. Same choice, different bill.

The five-year calendar: what boring actually buys you

The abstract benefit of boring technology is fewer surprises. The concrete benefit is that mature projects publish schedules, so your future obligations are knowable now.

PostgreSQL is the cleanest example. The PostgreSQL versioning policy states that the project releases a new major version about once a year, ships minor releases at least once every three months, and supports each major version for five years after its initial release. After that, a final minor release goes out and the version is end-of-life.

Five years, published, per version. You can put it on a calendar.

PostgreSQL 14, released September 30, 2021, gets its final release on November 12, 2026. PostgreSQL 18, released September 25, 2025, is supported through November 14, 2030. If you start a project on the current major version today, you have five years before anything is forced, and roughly a decade of overlapping supported versions to plan an upgrade inside of.

Compare that to a hosted service two years old with no published deprecation policy. You aren't choosing between "supported" and "unsupported" — you're choosing between a known schedule and an unknown one. The unknown one is not free just because nothing has gone wrong yet.

Boring tech gives you three related things. Predictable maintenance windows, so upgrades are scheduled rather than emergent. Migration paths that other people have already walked, because when thousands of teams face the same forced upgrade, someone writes the guide. And a large enough installed base that security fixes actually arrive — a five-year window means nothing if nobody is left to ship the patch.

If you're weighing data stores specifically, this durability dimension deserves as much weight as features. It's the argument I make in more detail in the PostgreSQL vs SQLite vs MongoDB comparison — and it matters most for the database, because the schema outlives every other decision you make.

A boring stack, itemized

Abstract advice is easy to agree with and hard to act on. Here's the concrete version: for each layer of a SaaS app, the boring default, the interesting alternative, and what the interesting option actually costs a solo non-technical founder.

| Layer | Boring default | Interesting alternative | What novelty costs you here | | --- | --- | --- | --- | | Database | PostgreSQL | Newer distributed or document stores | Thin AI training coverage; schema mistakes are expensive to reverse | | Framework | Next.js | Newer meta-frameworks | Fewer worked examples for auth, billing, and deploy paths | | Hosting | Vercel or similar managed platform | Self-managed containers or VPS | You inherit an ops job you can't staff | | Payments | Stripe | Newer processors, crypto rails | Payment bugs are revenue bugs; obscurity here is uniquely bad | | Auth | Managed auth (Supabase Auth, Clerk) | Hand-rolled sessions | Security failures you can't audit yourself | | Email | Resend, Postmark | Self-hosted SMTP | Deliverability is a full-time specialty | | Background jobs | Managed queue or scheduled function | Custom worker infrastructure | Silent failures with no observability |

The pattern across every row: the boring option isn't better on features. It's better on recoverability. When something breaks at 11pm and you're the only person who can fix it, what matters is whether the fix is findable.

That's why the Coding Capybaras boilerplate runs Next.js, Supabase, Stripe, and Resend — four choices that are individually unexciting and collectively very well documented. I didn't pick them because they're the most capable options in each category. I picked them because when I get stuck, I get unstuck.

It's worth noting the honest counterpoint: boring stacks have real ceilings. Postgres will eventually need read replicas and connection pooling. Managed hosting gets expensive at scale, and the line items that bite are rarely the ones on the pricing page. Those are good problems, and they arrive with revenue attached. Optimizing for them before you have customers is the mistake, not the boring stack.

The related question — which pieces to assemble yourself versus adopt wholesale — is really the same question in different clothing, and I've worked through the build versus buy framework separately.

When should you spend an innovation token?

Boring-by-default is a bias, not a rule. Taken to its extreme it means implementing everything in one language and never adding anything, which McKinley himself calls crazy. You need a way to add things.

The best question in the essay is also the cheapest to ask: consider how you would solve your immediate problem without adding anything new. McKinley notes that this question does double duty — it detects the case where the real "problem" is that someone wants to use the technology. If that's what's happening, abort. As a solo founder you are both the person who wants the shiny thing and the person responsible for operating it, which makes the question harder to ask honestly and more important to ask.

The answer is almost never "we can't do it." It's usually somewhere on the spectrum of "we could, but it would be awkward." Awkward is often fine. Awkward is frequently cheaper than a new dependency.

Three conditions I use before spending a token:

The novel thing is the product. If your differentiation genuinely requires a specific vector database or a specific inference runtime, spend the token. This is the entire reason to have tokens. What doesn't qualify is infrastructure a customer will never perceive.

You can articulate what makes the current stack prohibitively expensive. McKinley recommends writing this down, and the discipline is real. "Queries feel slow" is not an argument. "This aggregation takes 40 seconds at 2 million rows and I've already tried an index and a materialized view" is.

You have a plan for the thing you're replacing. New tools are often additive, but when they overlap something you already run, commit to migrating with a timeline. Otherwise you don't have a new tool — you have two tools and twice the surface area.

One more consideration specific to non-technical founders: check what your AI assistant knows before you commit. Ask it to write a non-trivial piece of code against the library you're considering, then verify whether the APIs it used actually exist. If it invents methods, you've just previewed every debugging session you'll have for the next year. That five-minute test has saved me more time than any comparison table, and it's the one piece of this advice that didn't exist when McKinley wrote the original essay.

Doesn't boring mean falling behind?

This is the objection worth taking seriously, because "boring" pattern-matches to "stagnant," and no founder wants to be the person who bet on the dying thing.

The data doesn't support the worry. In the 2025 Stack Overflow Developer Survey, which collected over 49,000 responses across 177 countries, PostgreSQL was the most-used database at 55.6% of all respondents — up from 48.7% the prior year — and it has ranked highest among databases on both the admired and desired lists since 2023, with 47% of developers saying they want to work with it in the coming year.

Postgres is thirty years old and getting more popular. That's what a healthy boring technology looks like: adoption compounding because the failure modes are known, which is the same property that makes it a good default for you.

There's a second-order effect too. As a technology's installed base grows, the quality of AI assistance for it improves, because there's more material to learn from. Boring technologies get better for non-technical founders over time, not worse. New ones start thin and only thicken if they win — and most don't.

The genuine risk isn't stagnation. It's ossification: refusing to reconsider a choice years after the conditions changed. The defense is a standing review, not a bias toward novelty. Once a year, ask which constraint is actually binding. Usually the answer is distribution, not infrastructure.

Frequently asked questions

Is "boring technology" the same as "old technology"?

No. Boring means well-understood, which correlates with age but isn't caused by it. A five-year-old tool with an enormous installed base and clear documentation can be boring; a fifteen-year-old tool nobody uses is just obscure. The test is whether other people have already hit and documented your failure modes.

How many innovation tokens does a solo founder actually have?

Fewer than three, in practice. McKinley's model assumes a team that can absorb operational load. A solo non-technical founder is the entire on-call rotation, so I'd budget one — spent on whatever makes the product different — and take defaults everywhere else until there's revenue.

Does using a boilerplate mean I've automatically chosen boring tech?

Not necessarily. Boilerplates vary widely in how conventional their stacks are, and some bundle newer tooling that hasn't accumulated much public troubleshooting material. It's worth checking each layer against the "could I find help at 11pm" standard before committing — I compare the major options in the SaaS boilerplate comparison.

What if the boring option is more expensive?

Compare total cost, not sticker price. A cheaper novel service that costs you two debugging days a month is more expensive than a managed service at three times the price, once you value your time at anything above zero. That said, most boring choices are also cheap, because commodity pricing follows commodity adoption.

How do I know if my AI assistant handles a technology well?

Test it directly. Ask for a realistic feature against that library, then check whether the functions and configuration options it used actually appear in the official documentation. Confident output referencing APIs that don't exist is the clearest signal that the training coverage is thin.

Should I switch stacks if I already picked something unusual?

Probably not on this argument alone. Migration is expensive and rarely the binding constraint on a pre-revenue product. Contain it instead: keep the unusual piece isolated behind a clear boundary so the rest of your stack stays conventional, and revisit once you have customers funding the decision.

The boring tech stack is a leverage decision

Choosing boring technology as a non-technical founder isn't a concession or an admission that you're not a real engineer. It's a leverage decision. Every hour you don't spend debugging an obscure error is an hour spent on the parts of the business only you can do — talking to customers, writing the landing page, figuring out why people sign up and don't come back. The stack is not where your advantage lives, and treating it as though it were is the most expensive mistake available to you.

The heuristic that survives contact with reality: pick the option with the largest number of people who have already hit your problem. Then spend your one innovation token on the thing your customers are actually paying for.

If you want a boring stack you don't have to assemble yourself, Coding Capybaras is the free Next.js, Supabase, Stripe, and Resend boilerplate I built for non-technical founders working with AI coding tools — deliberately unexciting, and documented for exactly this workflow.