The SaaS Tech Stack: What to Pick at Each Stage of Build
A SaaS tech stack is not a list of logos, it is a set of decisions with wildly different reversal costs. Some layers you can rip out on a wet Tuesday. Others fuse to your data model within weeks and stay for the life of the company. Founders consistently spend their attention on the cheap decisions and rush the expensive ones. Here is the order that actually works.
Don't pay full price to build this.All 105 SaaS tools below come with a discount code, a startup programme or free credits.Claim these perks →
The six layers every SaaS product needs
A SaaS product resolves into six layers: compute that runs your code, a database that holds state, an auth layer that decides who is who, a billing system that turns usage into money, analytics that tell you what people did, and a support surface where they complain. Everything else is decoration. Get these six wrong and no amount of framework debate rescues you.
The order matters more than the individual picks. Auth and billing sit closest to your data model and cost the most to replace, so they deserve real thought. Compute and hosting are nearly free to swap in year one because your app is small and mostly stateless. Founders reliably invert this, spending a fortnight on container orchestration and ten minutes on how a subscription upgrade behaves mid-cycle.
There is a second axis nobody mentions: which layers you are willing to let somebody else operate. Managed Postgres, a hosted auth provider and a payments processor collapse three operational burdens into three invoices. That trade is almost always correct before product-market fit, and almost always worth revisiting after, when the invoices start growing faster than the headcount they replaced.
Compute and hosting: the layer you can defer longest
For a web application, a platform host beats raw cloud for the first year or two. You get deploys from a git push, preview environments per branch, TLS handled, and no one on the team learning networking. Raw cloud wins when you need long-running workers, GPUs, unusual regions, or when your bill crosses the point where an engineer's time is cheaper than the platform margin.
Both routes have serious startup programmes. The large clouds hand out credits on a scale that covers most early workloads outright, and the platform hosts offer their paid tier free to early-stage companies with meaningful credit on top. Apply to more than one. There is no exclusivity clause and approval timelines vary from same-day to several weeks.
The failure mode is architecting for a scale you do not have. Splitting into services before you have a second team, or picking a region because it sounds fast, adds latency to every change you ship. Start with one deployable unit and one region near your users. Also watch egress and function invocation lines on the bill, because those are the two that surprise people.
Auth and billing are the two you cannot rip out later
Auth is not a login form, it is a decision about your tenancy model. Does a user belong to an organisation? Can they belong to several? Who can invite, who can revoke, and what happens to their data when they leave? Answer that before you write a schema, because retrofitting organisations onto a user-per-row product is a rewrite dressed up as a migration.
Billing carries the same weight. Proration, trials that convert, failed cards and retry logic, plan changes mid-period, invoices that a finance team will accept, and sales tax across jurisdictions are all harder than the checkout page. A processor handles payments and leaves tax to you. A merchant of record takes tax and compliance off your plate and takes a wider cut for it.
The specific failure worth naming: teams model subscription state in their own database, then let it drift from the processor's state. A webhook is missed, a customer downgrades, and your app keeps serving the higher tier for months. Treat the processor as the source of truth for entitlements, reconcile on a schedule, and never let a human edit a plan row by hand.
One database until it genuinely hurts
Postgres is the correct default and the burden of proof sits with anything else. It handles relational data, JSON documents, full-text search, queues via row locking, and increasingly vector search. Every one of those is worse than a dedicated system at large scale and better than a dedicated system at your scale, because it is one thing to back up, monitor and reason about.
The premature additions are predictable: a cache before there is a slow query, a message broker before there is a background job, a search cluster before anyone has searched. Each one adds a failure mode, a set of credentials, a monthly line item and a state that can disagree with your database. Add them when a specific measured problem demands it, not when the architecture diagram looks thin.
What people skip is restore. Automated backups are table stakes and mean nothing until you have restored one into a scratch environment and timed it. Do that in the first month, write down the number, and repeat it every quarter. Schema migrations deserve the same discipline: expand, deploy, backfill, contract, never a destructive change in the same release as the code that depends on it.
Instrumentation belongs at the start, not after launch
Product analytics installed on launch day gives you a baseline. Installed three months later it gives you a shrug. You want a small, deliberate event taxonomy from the beginning: signed up, activated, invited a teammate, hit the core action, upgraded. Five events named consistently beat two hundred auto-captured clicks nobody can interpret six weeks on.
Separate that from operational telemetry. Error tracking with source maps, structured logs you can search, and an external uptime check that pages someone are three different jobs. The generous startup programmes here run for a year on plans that would otherwise be four figures a month, which is exactly the period where you are least able to pay and most in need of the data.
The trade-off is real, so name it. Every analytics tool you add is another script on the page, another data processing agreement, another place customer data lives. Pick one product analytics tool and one error tracker, wire them properly, and resist the fourth dashboard. Sampling settings and retention windows matter more than the vendor once you are past a few million events.
Sequencing the build, and paying almost nothing in year one
A workable order: repository and CI first, then hosting with preview environments, then the database, then auth with the tenancy model settled, then billing, then analytics, then a support inbox. Each step should be shippable. If you cannot deploy something a stranger can log into by the end of week two, the stack is not the problem, the scope is.
Nearly every layer above runs a founder programme, and the overlap is what makes year one close to free: cloud credits that cover compute and storage, a hosted auth tier free to six figures of monthly active users, payments credits, analytics free for twelve months. The discipline is a calendar reminder sixty days before each one lapses, because they lapse quietly and the first invoice is full price.
Working out which programmes you qualify for is the tedious part, and it is what this directory exists to remove. The SaaS section is organised along exactly these layers, so you can see the current offer on compute, database, auth, billing and analytics side by side, with the real terms rather than a marketing page. Claim the ones that match the layer you are building next.
The offers mentioned above
Pulled live from the directory, so what you see here is what the listing says.
AWS
Cloud & Infrastructure
$200,000+ (by invitation)
CreditsLink on plan
Google Cloud
Cloud & Infrastructure
$350,000
CreditsLink on plan
Vercel
Developer Tools
Share of $8M+ in cohort credits
CreditsLink on plan
Supabase
Developer Tools
$500
CreditsCode on plan
Auth0
Security
$10,000
Free periodLink on plan
Stripe
Finance & Accounting
$100,000
CreditsLink on plan
PostHog
Data & Analytics
$50,000
Free periodLink on plan
SaaS codes, all in one place
105 listings in SaaS, with the redemption codes and programme links behind one subscription. Browsing is free.
Common questions
What is the minimum SaaS tech stack to launch?
A platform host, a managed Postgres, a hosted auth provider, a payments processor and one product analytics tool. Five vendors, all with free or credited startup tiers, and you can ship a paid product.
Should I build authentication myself?
No. Sessions, password resets, MFA, SSO and org membership are a permanent maintenance surface with security consequences. Buy it, and pick a provider whose organisation model matches how your customers are structured.
When should I move off a platform host to raw cloud?
When the platform bill exceeds what an infrastructure engineer's time costs, or when you need workloads the platform cannot run: long-running jobs, GPUs, specific regions, or strict data residency.
How much of a SaaS tech stack can be free in the first year?
Most of it. Compute, database, auth, analytics and error tracking all run startup programmes, several lasting a year or more. Payments processing fees are the one line you pay from the first transaction.