Boring is a feature

When you are building alone, every hour spent on infrastructure is an hour not spent on the product or on finding users. A boring stack is a set of technologies chosen because they are mature, well documented and unlikely to surprise you. Not because they are exciting.

The appeal is simple. With a boring stack:

  • Problems have known answers. Someone has hit your error before and written about it.
  • Upgrades are gradual. Mature tools change slowly and deprecate carefully.
  • Hiring help is easier. If you ever bring in a contractor, they already know the tools.
  • There is less to learn at once. You spend your novelty budget on the product, not the plumbing.

This does not mean old or bad. It means understood. The right boring stack for you is the one you already know well enough to debug at midnight.

What a boring stack often looks like

There is no single correct stack, but a typical boring setup for a small web SaaS might include:

Layer A boring choice Why it tends to work
Language and framework A mature server-side web framework you already know Batteries included: routing, forms, auth helpers, migrations
Database A single relational database such as PostgreSQL or SQLite Handles far more load than a small product needs; strong guarantees
Hosting One managed platform or one small virtual server Few moving parts; easy to reason about
Background jobs A simple queue backed by the same database No extra service to run until you need one
Email A transactional email provider Deliverability is hard to do yourself
Payments A well-known payment provider or merchant of record Tax, invoices and card handling handled for you
Frontend Server-rendered pages with light interactivity Less client-side state to manage

Many products in the Developer Tools and Productivity categories run on something close to this, and several of the GitHub entries let you read the setup directly.

The single-server argument

A surprisingly large number of small products can run comfortably on one modest server or one managed app instance with one database. A single machine today can handle a lot of requests for a typical CRUD app.

Consider a hypothetical tool with 500 active users who each make a few dozen requests a day. That is on the order of tens of thousands of requests daily, which averages to well under one request per second. Even with peaks many times higher, this is a light load for a single process backed by a relational database.

Splitting into multiple services, adding a cache layer and a separate search engine, or moving to a container orchestrator all make sense at some scale. For most indie products, that scale is far away, and the complexity costs you every day until then.

Where novelty is worth it

Boring is a default, not a rule. Some good reasons to pick something newer:

  • It is the product. If you are building a tool for a new framework's users, you need to use that framework.
  • It removes a whole category of work. A newer hosted database or auth provider that saves you weeks of setup can be the pragmatic choice.
  • You already know it deeply. If the "new" tool is the one you use every day at work, it is boring to you.
  • You want to learn it, and you are honest about that. Learning is a legitimate goal. Just recognize that it will slow the product down.

The mistake is choosing novelty by accident, because a tool is getting attention this month, without accounting for the time it will cost you.

Hidden costs to watch for

Some choices look boring but carry ongoing costs:

  • Many third-party services. Each one is a bill, an account, an outage risk and a possible price change. Five small services can quietly cost more than one bigger one.
  • Heavy client-side frameworks for simple apps. They can be great, but they add build tooling, state management and bundle size to a product that might not need them.
  • Usage-priced infrastructure with no cap. Serverless functions, managed queues and AI APIs can be cheap at low usage and painful when a user or a bot runs something in a loop. Set spending alerts and limits.
  • Your own custom framework. Building your own internal tooling is fun and almost always slower than using an existing one.

Keep it easy to run

The best stack for a solo maker is one that keeps running when you are not looking. A few habits help regardless of the tools:

  • Automate deploys so a release is one command or one push.
  • Back up the database automatically, and test a restore at least once.
  • Set up error reporting that emails or messages you, so you hear about failures before customers do.
  • Write down how to set it up from scratch. Future you, or a contractor, will be grateful.
  • Update dependencies regularly, a little at a time, rather than in a painful yearly batch.

A worked comparison

Say two makers build the same simple invoicing tool.

The first uses a familiar server-rendered framework, one relational database and one hosting platform. They ship in six weeks, pay a modest monthly hosting bill and spend an hour or two a month on maintenance.

The second uses a new frontend framework they are learning, a separate API service, a hosted auth provider, a managed queue, a serverless function platform and a document database. They ship in four months, juggle six vendor dashboards, and spend a day each month dealing with version changes.

Both products might work. The first maker had roughly three extra months to find users. For most indie products, that is the difference that matters.

FAQ

Is a boring stack bad for performance?

Rarely, at indie scale. Mature tools are usually well optimized, and most performance problems at this size come from inefficient queries rather than the choice of framework.

What if I need to scale later?

That is a good problem, and it usually arrives gradually. You can add caching, split out a background worker or move to a bigger database server when the numbers justify it. Starting simple does not stop you from growing.

Should I pick the stack with the most job listings?

Only if employability is one of your goals. For a product, pick what you can build and maintain quickly.

Related reading