SaaS tech stack for indie hackers: a practical pick

Stack debates get loud because everyone argues from the product they already shipped. Strip that bias out and a solo SaaS needs six decisions — framework, runtime, database, auth, payments, email — and every one has a boring default that works before the product earns anything.

What is the best tech stack for a solo founder SaaS?

The best tech stack for a solo founder SaaS is six boring layers: a TypeScript framework you can debug alone, a runtime with a real free tier, one relational database, session-based auth from a maintained library, one payment provider, and transactional email on your own domain. Deciding anything beyond those six is preference, not architecture.

Framework comes first because it shapes which tutorials you read and which errors have public answers. Next.js gives you the deepest ecosystem and the most familiarity inside every AI coding assistant; SvelteKit gives you the least ceremony per feature; Astro splits the difference by rendering pages as plain HTML and hydrating only what must be interactive, which suits a product with a heavy marketing site and a lean app — the full case is argued in Astro SaaS boilerplate. Let the runtime follow your database rather than the reverse: Cloudflare’s edge network and Vercel both carry free paths you can realistically stay on until traffic forces an upgrade, and your deploy story should be a command you can run from a fresh clone, as laid out in the deployment guide. Keep validation strict at the boundary — schema-check every request body, fail fast on missing environment variables instead of mid-request, and cover auth and payment paths with tests so a dependency bump cannot quietly break money movement. Every layer below inherits one rule: choose the option with the most boring documentation, because at 11pm you want a search result, not a forum thread from three majors ago.

Can I build a SaaS entirely on free tiers?

Yes — hosting, database, and email all have usable free paths, so a first SaaS can run at $0 per month in infrastructure until real traffic or real customers force an upgrade. The two costs you can never avoid are payment processing percentages and your own time.

Treat the free tier as a runway, not an architecture. An edge platform’s free path covers a marketing site and an early app; an edge SQLite database or a hosted Postgres free tier covers your first hundreds of users comfortably; transactional email allowances typically last through a beta if you only mail verified users. Startplate’s homepage frames the same starting line — a $0 free-tier point on Cloudflare with an edge database and no server babysitting — and its one-time tiers sit on the pricing section if you want the cost of the paid foundation next to the cost of the infrastructure. What free tiers do not give you is a guarantee: limits move, support is community-shaped, and deliverability suffers if email is treated as an afterthought. Read each provider’s current numbers on its own pricing page rather than trusting a cached blog post, and keep a simple discipline — check usage dashboards weekly, know the exact number at which each service starts charging you, and never attach a card you cannot watch. When paying users arrive, the upgrade should be a config change, not a rewrite; that is the real argument for picking portable, adapter-based services from day one. The month-by-month picture of where the $0 path ends is in the cheapest way to host a SaaS breakdown.

Next.js or SvelteKit — which should an indie hacker pick?

Pick Next.js if you want the largest ecosystem, the most prebuilt SaaS kits, and answers to almost any question; pick SvelteKit if you want less framework in your way and accept a smaller pool of ready-made components. Both have shipped profitable products, so the better one is the one you can debug alone.

Next.js’s advantage is gravity. The pool of tutorials, components, deployment guides, and assistant training data is simply deeper, which matters disproportionately when you are the only engineer and every unfamiliar error costs an evening. That gravity extends to commercial kits: most paid boilerplates on the market are Next.js-first, so choosing Next keeps your future options open — the current landscape is mapped in best SaaS boilerplates for 2026. The cost is framework surface: server rendering conventions, caching semantics, and routing patterns have shifted across releases, and you will spend real hours re-learning them when a major version lands.

SvelteKit’s argument is output, not ecosystem. You write less code per feature, the mental model stays small, and pages ship less JavaScript by default because the framework does less by default. The cost appears when you need a component that exists in twenty React libraries, when a dependency assumes React, or when you want to buy a commercial kit — nearly all of them target React. Hiring later is also thinner. The pragmatic rule: choose Next.js if you expect to buy a kit, hire help, or lean heavily on ecosystem packages; choose SvelteKit if you are the permanent team and writing speed beats breadth of choice. If neither excites you, the third path is covered in the Astro breakdown, and framework choice is only decision one of six.

Stripe vs Lemon Squeezy for indie hackers?

Stripe is the pick when you want the deepest API surface, the most integrations, and full control of checkout; Lemon Squeezy is the pick when you want a merchant of record to absorb much of the global sales-tax and VAT paperwork. Solo founders selling straightforward subscriptions usually start on Stripe; sellers facing cross-border tax obligations often prefer the merchant-of-record route.

Both take a percentage of every transaction, and that cost belongs in your pricing math from day one regardless of which logo you choose. Stripe gives you subscriptions, a customer portal, webhooks, tax add-ons, and an integration path for essentially every tool you will add later; the trade is that you become the seller of record, so tax registration can become your problem as you sell across borders. Lemon Squeezy flips that arrangement: it sells on your behalf as the merchant of record, absorbing much of the VAT and GST administration in exchange for convenience and a different fee shape. Check both against your actual country and product before deciding — supported regions and fee schedules change, and only the current pricing pages are authoritative.

Whichever you pick, keep the integration behind a thin layer instead of smeared across your codebase: checkout creation, webhook signature verification, and one query that answers “what plan is this customer on?”. That indirection is what makes a future switch cheap. A shared payment layer with Dodo Payments as the default path plus adapters for both Stripe and Lemon Squeezy is exactly how Startplate handles the same problem, and the wiring steps are documented in the payments guide.

What database and auth should a small SaaS use?

For a small SaaS, use SQLite at the edge (Turso/libSQL or D1) or a hosted Postgres (Supabase or Neon) for data, and a maintained auth library that ships sessions, verification, resets, 2FA, and organizations for identity. Hand-rolled JWT auth is the most expensive shortcut a solo founder can take.

The database decision is smaller than it looks. SQLite-class systems now replicate at the edge, and a solo product rarely stresses them until scale is genuinely large. What matters early is that migrations are files you can run locally and in production, and that the schema models tenancy deliberately: organizations, members, and invitations tables from day one if teams will ever exist, because retrofitting tenancy rewrites primary keys, the authorization layer, and every query you already shipped. Postgres remains right when you need extensions or JSON-heavy analytics; SQLite wins on operational silence — no pooling, no connection limits to babysit at 3am. Whichever store you choose, take backups seriously from the first paying customer: on managed providers it is a checkbox, not a weekend project.

On auth, buy the boring part. Your library should already model email and password login, social providers, email verification, password resets, 2FA, magic links, and — if teams exist — organization membership, with session storage that behaves under concurrent tabs. Verification and reset flows need transactional email on your own domain, and that integration is minutes rather than days when the auth and mail layers were designed to meet. Walk the full flow set in the auth guide, and if you are deciding how much foundation you need before buying anything, the line between a thin starter and a full foundation is drawn in starter kit vs boilerplate.

The short version

A solo SaaS needs six decisions, and each one has a free-tier default that survives contact with your first users. Choose boring, documented layers — a framework you can debug, an edge runtime, SQLite or Postgres, maintained auth, one payment provider, domain email — and keep every swap cheap behind thin adapters. Next.js wins on gravity, SvelteKit on economy, Stripe on control, Lemon Squeezy on tax paperwork. Revisit each choice when revenue makes the upgrade obvious, not before. None of these decisions has to be permanent — all of them are cheaper to make before launch than after.