The Boring Stack: What I Would Pick for a New SaaS in 2026

Most stack debates are about taste dressed up as engineering. The Hacker News thread on "Rust vs Go for a side project" is, deep down, a thread about whose tribe you want to be part of. The actual cost of switching languages is usually trivial compared to the cost of getting product-market fit, and almost no early-stage SaaS ever fails because the language was wrong.

That said: I have shipped four production APIs in ten days, all of them generating real PDF invoices, monitoring real cron jobs, evaluating real feature flags, capturing real webhooks. They all run on the same boring stack. Here is what I would pick on day one of a new project, and what I would not — for entirely practical reasons.

FastAPI for the API layer

Python because the ecosystem is enormous, mature, and boring. FastAPI specifically because it gives you OpenAPI generation, async support, and Pydantic validation for free, and because the team behind it ships sane defaults. If your bottleneck is HTTP request handling, you will discover that you should never have written your own.

What I would not pick: a microservices framework like Nest, Spring Boot, or anything that requires more than five files to do "GET /users." For a one-person team or a small product, the framework should fade into the background.

SQLite for the database

This is the recommendation that gets pushback. The pushback is almost always wrong for the first year.

SQLite handles thousands of writes per second on a modest VPS. It has a smaller operational footprint than any networked database. It has no separate process to manage. It has no replication lag. It backs up by copying a file. It has the most tested and battle-hardened query engine in the industry — your phone runs SQLite, your browser runs SQLite, every airliner runs SQLite.

You will know when to graduate to PostgreSQL: it will be when a single writer is too slow, or when you need a concurrent multi-machine deployment, or when a specific Postgres feature (JSONB, advanced full-text search, array types) becomes load-bearing. None of those are day-one problems.

What I would not pick: MongoDB, DynamoDB, or any document store as the primary store of a SaaS that has relational data. Almost all data is relational. The document-store appeal usually evaporates around the third feature.

Docker Compose for orchestration

One file, one command, every container labeled and networked. Compose is enough for a single VPS running a dozen services. It is enough for staging environments. It is enough for many production deployments — most apps do not need the full Kubernetes machinery.

What I would not pick: Kubernetes. Not for a single-team product, not for a single-VPS deployment. Kubernetes is excellent for the problems it solves; those problems are not yours yet.

Caddy for the reverse proxy

Caddy handles SSL automatically via Let's Encrypt. It auto-renews. The configuration syntax fits in a paragraph for most apps. It handles HTTP/3, gzip, security headers, redirects, and rate limiting without plugins.

What I would not pick: Nginx for a new project. Nginx is more battle-tested at scale, but the operational tax of managing certbot, reload commands, and 30-line server blocks for what Caddy does in 3 lines is not worth it for the first thousand customers.

Stripe for billing

Boring, expensive, and worth every cent. The integration time saved versus rolling your own — even via Lemon Squeezy or Paddle — is enormous. The webhook spec, the test mode, the documentation, the tax handling: all of it is invisible because it works.

What I would not pick: a "we'll add billing later" approach. Adding billing on day one is faster than adding billing on day 90, when you have to retrofit pricing tier metadata into a thousand existing accounts.

Plausible for analytics

Self-hosted, GDPR-friendly, privacy-respecting, and small enough to fit on the same VPS. Or use the hosted version. Either way, the lightweight, no-cookie, single-script approach saves you from cookie banners and from the dread of the GA4 dashboard.

What I would not pick: Google Analytics 4. Not because it is bad — it is fine — but because the operational and privacy overhead is disproportionate to what most small SaaS projects actually use. The number of teams I have seen who installed GA4 and then never opened the dashboard is high.

Listmonk for email

For newsletters and transactional, Listmonk plus a transactional SMTP provider (Postmark, Resend, Mailgun) handles 99% of what most products need. The Mailchimp price tag is worth avoiding when your list is under 10,000.

The pattern

If you trace the choices, they share a property: each piece does one thing well, has been around for at least five years, and has documentation that fits in a single tab. None of them are exciting. None of them are conference talks. They will not get you on Hacker News.

They will let you ship.

What I would actually spend time on

Saving days on the stack lets you spend days on what matters: the product itself. Specifically:

• Onboarding flows that are short and don't require a credit card.
• API documentation that has copy-pasteable curl examples.
• Error messages that tell users what to do, not what failed.
• A pricing page with three tiers and clear quotas.
• One landing page that loads in under a second on a phone.

None of that is about the stack. All of it is about the customer's first hour with your product.

The exception

If you are building something where the stack is the product — a database, a runtime, a developer tool whose pitch is "this is faster" — then yes, your stack choices are part of the marketing. Pick the exciting thing. Sell its strangeness.

Otherwise, pick the boring thing. Save your novelty budget for the parts of the product the customer actually sees. The most underrated trait in production software is invisibility — and the boring stack lets you build invisible software fast.

If you want to see what this stack actually looks like running, check out the four production APIs we built on it: DocuMint (PDF invoices), CronPing (cron monitoring), FlagBit (feature flags), and WebhookVault (webhook debugging). Same stack, four products, ten days. The boring stack works.