Pick Boring Technology

Dan McKinley wrote the definitive piece on this in 2015: "Choose Boring Technology." The core argument is simple. You have a limited capacity for novelty. Every new technology you adopt costs you in learning, debugging, and operational surprises. Spend that budget on your product, not your infrastructure.

PostgreSQL is boring. It also handles 99% of startup data needs for years. Rails is boring. It also powers Shopify, GitHub, and Airbnb. React is boring. It also has the largest ecosystem of any frontend framework.

Boring is not an insult. Boring means battle-tested, well-documented, widely understood, and unlikely to surprise you at 3am on a Saturday.

The Innovation Token Budget

McKinley's key insight is the concept of innovation tokens. Every company gets about three. Each time you adopt a technology that is not industry-standard, you spend a token.

Company A (3 tokens spent well):
- PostgreSQL (boring, 0 tokens)
- Django (boring, 0 tokens)
- React (boring, 0 tokens)
- Novel ML recommendation engine (1 token — core product)
- Custom real-time collaboration protocol (1 token — core product)
- New pricing model for the market (1 token — business innovation)

Company B (3 tokens wasted):
- CockroachDB (1 token — why not PostgreSQL?)
- Elixir/Phoenix (1 token — cool but small hiring pool)
- Svelte (1 token — nice but smaller ecosystem)
- Generic CRUD product (0 tokens left for actual innovation)

Company A spent its tokens on things that differentiate the product. Company B spent its tokens on infrastructure nobody will ever see. Both companies have the same number of problems, but Company B's problems are self-inflicted.

What Counts as Boring

Boring technology has these properties:

At least 5-10 years old
Used by many companies in production
Well-documented with extensive Stack Overflow answers
Easy to hire engineers who know it
Failure modes are well-understood
Has a large ecosystem of tools and libraries

Boring databases:    PostgreSQL, MySQL, SQLite, Redis
Boring languages:    Python, JavaScript/TypeScript, Ruby, Go, Java
Boring frameworks:   Rails, Django, Next.js, Express, Spring Boot
Boring hosting:      AWS, GCP, Heroku, Vercel, Railway
Boring queues:       Redis (pub/sub), SQS, RabbitMQ
Boring search:       PostgreSQL full-text search, Elasticsearch

Not boring (spend a token if you use these):

Novel databases:     CockroachDB, SurrealDB, EdgeDB
Novel languages:     Rust (for web apps), Zig, Gleam
Novel frameworks:    Bleeding-edge meta-frameworks
Novel infra:         Self-hosted Kubernetes, custom service mesh

There is nothing wrong with the "not boring" list. These are often technically superior. But superior technology that your team does not deeply understand is worse than adequate technology that your team knows inside and out.

The Boring Stack for Startups

If you are starting a new startup today and want to minimize technology risk, here is the boring stack:

Frontend:     Next.js or React + Vite
Backend:      Next.js API routes, Rails, Django, or Express
Database:     PostgreSQL
Cache:        Redis
Hosting:      Vercel, Railway, or Heroku
Auth:         Auth0, Clerk, or NextAuth
Payments:     Stripe
Email:        Resend, SendGrid, or Postmark
File storage: S3 or Cloudflare R2
Monitoring:   Sentry for errors, basic cloud metrics for everything else

This stack will handle everything from zero to millions of users. It is not the most technically interesting stack. It is the stack that lets you focus on your product.

Shopify ran on Rails and MySQL for years while scaling to billions in GMV. GitHub ran on Rails and PostgreSQL. Airbnb ran on Rails. These are not toy frameworks for toy companies.

The point is not that this exact stack is right for you. The point is that a stack composed entirely of boring, proven components lets you ship product instead of fighting infrastructure. Pick the boring stack your team knows best and build your product on top of it.

But What About Performance?

The most common objection to boring technology: "it is not fast enough."

In nearly all cases, this is premature worry. A Rails app on a single server can handle thousands of requests per second. A Django app with PostgreSQL can handle millions of database rows without breaking a sweat. A Next.js app on Vercel can serve global traffic with edge caching.

If you have a genuine performance constraint — you are building a high-frequency trading system or a real-time multiplayer game — then yes, pick your technology accordingly. But most startups are building CRUD apps with some business logic. Boring technology handles this effortlessly.

Instagram served tens of millions of users on Django and PostgreSQL. They did not switch to a "faster" framework. They optimized their Django app and their PostgreSQL queries. The boring technology was not the bottleneck — their approach to using it was.

When performance actually matters:
- Response time > 500ms on critical paths
- Database queries timing out under normal load
- Server costs exceeding revenue
- Users complaining about speed

When performance does not matter yet:
- You have fewer than 10,000 users
- Your server CPU is below 30%
- Nobody has complained about speed
- You are optimizing theoretical future load

The Hiring Argument

You will need to hire engineers eventually. When you do, the size of the talent pool matters enormously.

"We use Python/Django" -> Thousands of candidates
"We use Ruby/Rails"    -> Thousands of candidates
"We use TypeScript"    -> Tens of thousands of candidates
"We use Elixir"        -> Hundreds of candidates
"We use Gleam"         -> Dozens of candidates

This does not mean Elixir or Gleam are bad. It means using them costs you a hiring token. If your product demands what they uniquely offer (massive concurrency, fault tolerance), the token is well spent. If you are building a standard web app, it is not.

Stripe chose Ruby partly because the Ruby community was dense with talented web developers. They could hire fast. When they eventually needed better performance in specific areas, they wrote those components in other languages. But the core team could hire and onboard quickly because the primary language was widely known.

The hiring argument is especially important for startups planning to raise funding and grow. Investors ask "can you scale the team?" If your stack makes hiring hard, that is a real business risk, not just an engineering inconvenience.

When Boring Is Wrong

Boring technology is a default, not a commandment. There are legitimate reasons to pick something non-standard:

Your problem domain demands it. Building real-time systems at scale? Elixir and the BEAM VM are genuinely better for this. Building systems-level software? Rust is the right choice. Building ML infrastructure? Python is the only sane option regardless of its other trade-offs.

Your team deeply knows the non-boring thing. If your three cofounders are all Elixir experts, use Elixir. The "boring" advantage is about reducing unknowns. A technology your team knows deeply has fewer unknowns than a "boring" technology nobody on the team has used.

The boring option genuinely cannot do what you need. If you need global distributed transactions, PostgreSQL will not cut it. If you need sub-millisecond latency, Python will not cut it. Know the actual limits of boring technology and switch when you hit them.

The Operational Cost of Novelty

Novel technology has hidden costs that only become apparent after you have been running it in production for months.

Debugging is harder. When your boring PostgreSQL query is slow, you Google the explain plan and find 50 blog posts about it. When your novel database has a mysterious performance problem, you file a GitHub issue and wait.

Upgrades are riskier. Boring technology has well-documented upgrade paths tested by thousands of companies. Novel technology has changelogs that say "breaking changes" without clear migration guides.

The bus factor. If the one engineer who chose the novel technology leaves, the rest of the team inherits a system they do not understand. With boring technology, any new hire can get up to speed quickly.

Community support gaps. Boring technology has answers on Stack Overflow, maintained libraries for common tasks, and consultants who specialize in it. Novel technology has a Discord server with 200 members and a "getting started" guide that is three months out of date.

Hidden costs of novel technology:
- Debugging time:         2-5x longer for unfamiliar failure modes
- Hiring onboarding:      Weeks instead of days
- Library availability:   Build vs find (build takes longer)
- Operational knowledge:  Trial and error vs established practices
- Upgrade risk:           Higher chance of breaking changes

These costs are invisible when you are evaluating technology in a proof-of-concept. They become very visible six months into production. Factor them into your decision.

Common Pitfalls

Resume-driven development. Choosing technologies because they look good on a resume rather than because they solve your problem. Your startup is not a learning playground — it is a business. Save the experimenting for side projects.

Confusing "boring" with "outdated." PostgreSQL is boring. It is also one of the most actively developed databases in the world. Boring means stable and proven, not abandoned. PostgreSQL gets major new features every year.

Switching stacks out of boredom. After six months of writing Rails, the framework feels stale. You start reading about the hot new thing. This is your brain wanting novelty, not your product needing a better framework. Recognize the impulse and ignore it.

Assuming boring means no learning. You will learn enormous amounts building a product on boring technology. The learning is about product development, user needs, and scaling — not about the novelty of the technology itself. Understanding PostgreSQL deeply is more valuable than surface knowledge of five databases.

Picking boring technology you do not know. If nobody on your team knows Rails, Rails is not boring for you — it is new. The "boring" calculus is relative to your team's experience. A technology is only boring if you understand its failure modes.

Following the herd without thinking. "Everyone is using X" is not a reason to use X. "X solves our specific problem well and is widely supported" is a reason. Think about your needs, not the trending list on GitHub.

Ignoring your team's strengths. If your founding team has deep expertise in a specific technology, even if it is not the most popular choice, that expertise is worth something. A team that is highly productive in a less common stack may outperform a team learning the "right" stack from scratch.

Over-indexing on benchmarks. "Framework X handles 100,000 requests per second, Framework Y only handles 10,000." You will not see 10,000 requests per second for years, if ever. The benchmark is irrelevant. What matters is how fast your team can ship features with each framework.

Choosing a stack because a famous company uses it. Netflix uses Java. Google uses Go. Facebook uses Hack. These companies chose those technologies for reasons specific to their scale, their team, and their history. Your startup has none of those things in common. Choose technology based on your constraints, not theirs.

Key Takeaways

You have a limited innovation budget. Spend it on your product, not your infrastructure.
Boring technology is battle-tested, well-documented, and widely understood. These properties are more valuable than technical novelty.
PostgreSQL, Rails/Django/Next.js, and standard cloud hosting handle the vast majority of startup needs for years.
Performance is almost never a reason to avoid boring technology at the early stage. Optimize when you have evidence, not anxiety.
Hiring is dramatically easier with mainstream technology. This matters more than you think when you need to grow the team.
Novel technology has hidden operational costs: harder debugging, riskier upgrades, smaller community support, and higher bus factor risk.
Break the boring rule only when your problem domain demands it, your team deeply knows the alternative, or you have hit real limits of the boring option.
"Boring" is relative to your team. A technology is boring if your team deeply understands its failure modes, not because it appears on a list.
The companies that win are boring where it does not matter and innovative where it does. Put your creativity into the product, not the plumbing.
When in doubt, pick the technology with the most Stack Overflow answers. You will need them at 2am.