What Do You Need to Build a SaaS? The Honest List

You need five core parts to launch a SaaS: user authentication, a database, application hosting, a payment processor, and a deploy pipeline. A solo founder can run all five for under $50 a month with off-the-shelf tools. Everything else — a polished design system, a mobile app, a data warehouse — is optional until customers ask for it. Start with the five. Add the rest when revenue justifies it.

What do you actually need to build a SaaS?

You need five things: authentication, a database, hosting, payments, and a deployment pipeline. Each maps to a mature, cheap tool you don't have to build from scratch. Everything past this list is a want, not a need. A working product with those five parts can charge money on day one.

Notice that four of the five have a free starting tier. You pay for payments only when you earn.

How much does it cost to build a SaaS?

A bootstrapped SaaS can go live for $20-$50 a month in infrastructure, plus payment fees. Stripe charges 2.9% + $0.30 per successful card charge, per Stripe's published pricing, so payment cost scales with revenue rather than hitting you upfront. Your fixed costs are hosting and the database.

Here is a realistic starting budget for one founder:

• Domain name: $10-$15 a year.
• Managed database: $0 on a free tier, ~$20 once you have real users.
• App hosting: $0 to start, ~$20 at modest traffic.
• Email sending (password resets, receipts): $0 up to a few thousand emails.
• Stripe fees: only when a customer pays.

Most of the AWS Free Tier and equivalent offers cover a pre-revenue product completely. Your real early cost is your time, not your server bill.

What tech stack should a solo founder pick?

Pick the stack you already know — shipping speed beats theoretical scale. For most solo founders that means one language across the front and back end, a managed relational database, and a host that deploys straight from git. You will not out-grow a sensible default before you have paying customers.

A reliable default stack looks like this:

1. One language end to end (JavaScript/TypeScript, Python, or Ruby) so you switch context less.
2. A managed PostgreSQL database — battle-tested, relational, and well documented in the PostgreSQL documentation.
3. A hosting platform that redeploys on every git push.
4. Stripe for billing, because rolling your own payments is a compliance trap.

Resist the urge to add Kubernetes, microservices, or a message queue. Those solve scale problems you do not have yet. Boring, monolithic, and shipped beats clever and unfinished.

How we ship a SaaS feature at Botensten

We ship one feature at a time, behind the real interface, and we test it against a live database before we call it done. We learned that the hard way. Early on we shipped a comment feature that passed every unit test, then broke in production because the tests called one helper directly and skipped the validation gate the real route used. The feature was "verified" and still didn't work.

Now the rule is simple: a feature is real only when it works through the actual API, persists real data, and survives a page reload. We build the smallest slice that a user can touch, wire it end to end, then screenshot the running page before we commit. If it isn't visible and clickable, it isn't finished.

That discipline is cheaper than it sounds. We run a small monolith, deploy on git push, and keep the whole stack under a few dollars a day. The constraint forces focus: when you can't hide behind a big team or a big budget, you only build what earns its keep. This is the renter-to-owner shift we teach — you own the code your business runs on, so every line is a decision you can defend.

Should you build it yourself or hire a team?

Build v1 yourself. A solo founder who can code a rough version learns faster and spends far less than one who hires out the first release. You will change the product ten times before it fits the market, and you cannot afford to pay a contractor for each pivot. The Lean Startup by Eric Ries makes this case well: your first job is validated learning, not clean architecture.

Hire only when you hit a wall you can't clear and a customer is already paying to clear it. Good triggers to bring in help:

• You have paying users and a feature backlog you cannot ship fast enough.
• A hard problem (billing edge cases, security review) needs a specialist.
• Support volume eats the time you need to build.

Until then, staying solo keeps your burn near zero and your feedback loop tight.

What do you build first?

Build the single feature a customer will pay for, and nothing else. Skip settings pages, admin dashboards, onboarding tours, and dark mode until someone hands you money. Most first versions die from doing too much, not too little.

A sane build order:

1. The core action that delivers the value (the thing they'd pay for).
2. Authentication, so users have accounts.
3. Stripe checkout, so they can pay.
4. The minimum around those three to make them usable.

That is a chargeable product. As The SaaS Playbook by Rob Walling argues, momentum comes from charging early and iterating with real customers — not from a longer feature list. Get to a paid transaction, then let paying users tell you what to build next.

Related reading

• How Do I Build a SaaS? A Builder's Honest Playbook
• Should You Build a SaaS? The Honest Answer
• How Do I Launch a SaaS Product? The Operator Playbook