The SaaS tech stack for solo founders
The right stack for one person is the one that never wakes you up. Every choice below was made by asking what breaks at 2am and who fixes it.
The short version
- One of each layer, nothing self-hosted. A framework, a managed database, hosted auth, Stripe, an email API, a deploy host, one analytics tool. Done.
- Boring is a feature. Mainstream tools have the most documentation, the most Stack Overflow answers, and the most training data for your AI assistant.
- Pay for anything with state. Databases and file storage are where a solo founder cannot afford to be the on-call engineer.
- Pick the framework you already know. The stack that ships beats the stack that is technically better.
- Change nothing until a limit costs money. Rewrites are how solo projects spend a year standing still.
What makes a stack right for one person?
That every part of it is run by someone else. You are the product team, the support desk and the marketing department; the one job you cannot also take on is operations. A solo stack is a set of managed services with your code in the middle, and the less of it you administer, the more of it you can sell.
Teams optimise for control and cost at scale. You optimise for sleep. A Postgres server on a cheap VPS saves twenty dollars a month and costs you the weekend the disk fills up. A clever queue system is elegant until it stalls silently and a customer emails to ask why nothing has happened since Tuesday. Neither of those is a hypothetical; both are the standard way a one-person SaaS quietly dies.
Every service you host is a pager you carry.
The rule that follows is short: one tool per layer, hosted, mainstream, and nothing you could not debug alone at 2am with the documentation open.
What does the stack actually look like?
Seven layers, one default each. A full-stack web framework, a managed Postgres, auth from the framework or a hosted provider, Stripe, a transactional email API, a platform-as-a-service host, and one privacy-friendly analytics tool. Every default below has a free tier that covers the first customers.
| Layer | Default pick | Why this one |
|---|---|---|
| Framework | Next.js (or the full-stack framework you already know) | Front and back end in one repo, one deploy, and the most examples in existence |
| Database | Managed Postgres (Supabase or Neon) | Backups, scaling and upgrades are someone else's job; Postgres does everything |
| Auth | The framework's auth library, or Clerk / Supabase Auth | Password reset, magic links and OAuth are solved problems; do not re-solve them |
| Billing | Stripe | Checkout, subscriptions, invoices, tax, dunning: one integration covers all of it |
| Resend or Postmark | Transactional email that lands in the inbox, with an API that takes ten minutes | |
| Hosting | Railway, Vercel or Fly | Git push to deploy, logs in a browser, no servers to patch |
| Analytics | PostHog or Plausible | Enough to see activation and churn without a data team |
If you already know Rails, Laravel or Django, substitute it for the framework row and keep everything else. The point is not the specific brand. It is that each row has exactly one entry, every entry is hosted, and none of them requires you to learn something new before you can ship the workflow you scoped.
Why does boring beat better?
Because the cost of a tool is not its price, it is the hours you spend when it misbehaves. Mainstream tools have had every failure mode hit, documented and answered by thousands of people before you. The newer, better tool has had a few hundred, and you may be the first to find yours.
This matters twice as much now that AI assistants write most of the code. A model is good at a framework in proportion to how much of it existed on the public internet when it was trained. Ask it for a Next.js route with Stripe webhooks and Postgres and you get working code on the first try. Ask for the same thing in a framework released eight months ago and you get confident code that calls functions which do not exist. The boring stack is the one your assistant is fluent in.
- Documentation depth. Every error message you will see has already been searched.
- Integration coverage. Stripe, Resend and the auth providers all ship official examples for the mainstream frameworks first.
- Hiring later. If the product works and you ever bring in help, they will know it.
- Longevity. The tools in the table have been around long enough to outlast your first three years.
What should you never self-host?
Anything that holds state: the database, file storage, and the email queue. A crashed app server restarts. A corrupted database, a lost bucket or a stuck mail queue is a customer-facing incident that you, alone, will be explaining while also trying to fix it.
The stateless parts are forgiving. If the app falls over, the host restarts it, and the worst case is a minute of downtime. The stateful parts are unforgiving, and the difference between a managed Postgres and one you installed is not performance. It is the point-in-time backup that exists whether you remembered to set it up or not.
Turn on the backups on day one and test a restore on day two. Managed databases make this a checkbox. The reason to do it before you have customers is that after you have customers, it is the first thing you will wish you had done.
Where do secrets, errors and uptime live?
Secrets in the host's environment variables and nowhere else, errors in a hosted tracker with email alerts, and uptime in a free ping service that texts you when the site is down. Three settings, one hour, and the difference between hearing about an outage from a monitor and hearing about it from a customer.
None of this is glamorous, and all of it is what "run alone" means in practice. API keys go into Railway or Vercel's environment settings, never into the repository, and the repository has a .env.example that lists their names without their values. An error tracker such as Sentry has a free tier that catches the exception a customer hit at midnight and emails you the stack trace, which is the only way you will ever learn about it. An uptime check every minute from an outside service costs nothing and is the closest thing to an operations team one person can have.
Set all three up before the first customer, because the day after the first customer is the day you no longer have time to.
What is deliberately missing?
Microservices, Kubernetes, a separate API and front end, a message queue, a caching layer, and a second database of any kind. Each is a real tool for a real problem, and none of those problems shows up before a few thousand customers.
The pull toward these is strong because they are what engineering blogs are about. But engineering blogs are written by teams describing what they needed at scale, and you are one person describing what you need at zero. A single Next.js app talking to a single Postgres, with Stripe webhooks and a cron job, is the entire architecture of a surprising number of products that found their first customers and kept them. Add the next layer when a specific customer-facing problem demands it, and write down what the problem was.
How do you keep the stack from growing?
Write it down, one line per layer, and treat additions the way you treat features: they go on a list, and the list is reviewed when a paying customer is affected. A stack that lives in your head acquires a tool every time you read something interesting.
The stack page sits next to the scope page. It says which framework, which host, which database, and the one place secrets live. When you use an AI assistant to build, this page goes into the context at the start of every session, so it stops suggesting Redis for a problem that a database column would solve. The whole route from idea to recurring revenue is easier with fewer moving parts, and the parts only stay few if someone is counting.
Frequently asked questions
Does the language matter?
Less than you think, as long as it is one of the big ones. TypeScript, Python, Ruby and PHP all have a mainstream web framework, a Stripe SDK, and enough public code that an AI assistant has seen every problem you will hit.
Should I use a no-code tool instead?
For a landing page and a waitlist, yes. For the product, usually not. No-code tools cap what you can build and charge you more as you grow, and the day you outgrow one you rebuild from zero.
Is a managed database really necessary at this size?
Yes, because the thing you are paying for is backups, not capacity. A free-tier managed Postgres with automatic backups is worth more than a self-hosted one with none.
What about mobile?
A responsive web app, until a paying customer says otherwise. Native apps double the surface area, add app-store review to every release, and take a cut of subscriptions.
When should I change the stack?
When a specific limit is costing you money, and not before. Boredom, a new framework release and a blog post about scale are not reasons.
The system behind this, written down
Everything above is the map. The Income Loop is the work inside it: modules 0–6 from the problem you solve to the offer that pays for it, plus ten traffic paths: the deeper post banks, the content sales systems and the full software build sequence, in one place.
Get The Income LoopNot ready to pay for anything? The Basic Income Loop is free and includes a complete seven-day starter for Threads, Instagram or software, enough to find out which one suits you before spending anything.