Guide · SaaS & B2B tools

How to build a SaaS product from scratch in 2026: the parts that make it SaaS, and where AI tools stop

How to build a SaaS product from scratch: seven steps, the SaaS-only parts (tenancy, billing, roles), and where no-code and Claude Code stop.

By Akash Bansal, founding engineerUpdated 5 November 20269 min read

Most "how to build a SaaS" guides are a list of phases: research, design, develop, test, launch. That list is true of any software, so it doesn't help much. What I want to give you instead is the short list of parts that make a product SaaS, the order to build them in, and an honest line on where no-code and AI coding tools are enough and where they stop.

My evidence is two products I built: KAF OS, a multi-tenant customer-onboarding SaaS with SLA-tracked stages and an immutable audit trail, and NextMantra, an AI recruiter I built solo and run in production on Next.js, NestJS, PostgreSQL and AWS.

How do you build a SaaS product from scratch?

You build a SaaS product in seven steps: pick one painful workflow, prove someone will pay, write a narrow scope, set up tenancy and sign-up, build the core workflow, add billing and an admin view, then launch to a handful of customers and iterate. The order matters more than the tools, because the early steps decide what you never have to build.

1. Pick one workflow for one type of company. "Onboarding for B2B software vendors", not "a platform for operations teams".
2. Prove someone will pay before you build. Interviews, a landing page, a paid pilot. I wrote a separate guide on how to validate a startup idea before building.
3. Write the scope on one page. Who the user is, the one job version one does, and what is out.
4. Set up tenancy, sign-up and roles. The foundations that are cheap now and expensive later.
5. Build the core workflow. The thing customers came for. It gets the most time.
6. Add billing and an admin view. So customers can pay and you can run the business without an engineer.
7. Launch to five to ten customers. Watch them use it, fix what breaks, then widen the door.

What makes a SaaS product different from an app?

A SaaS product is an app that many customer companies share, that they pay for on a schedule, and that they trust with their data. Those three facts add a handful of parts an ordinary app doesn't need. This table is the real build list.

Everything in the last row is where SaaS scopes balloon. Each one is reasonable on its own. Together they turn a ten-week build into a six-month one. Wait until a customer who is already paying asks for one by name.

Why does multi-tenancy have to come first?

Because every table and every query depends on it. Multi-tenancy means one running system serves many customer companies, with each company's data kept separate. If you add it later, you touch every query you've written, and any one you miss can show one customer another customer's data.

On KAF OS I used the simple approach: one database, a tenant ID on every row, and the database itself refusing reads across tenants, as well as checks in the application code. Two locks, so a single missed filter can't leak data. Separate databases per customer sound safer but are much more work to run; save them for the enterprise contract that demands it. AWS's SaaS Lens covers the trade-offs between these models if you want the long version.

How should you design the first five minutes after sign-up?

Design them as a short, fixed path to the first useful result, because that's when a trial user decides whether to stay. In SaaS this is called activation. On KAF OS it's three steps: create the company, assign a workflow, assign an agent. After those three, a new customer has a live onboarding running.

Write your own three steps down before anyone designs a screen. If you can't get a new customer to a real result in three or four steps, the product is too broad, and that's a scope problem, not a design problem.

How do you add subscription billing without building a billing system?

Buy it. Subscription billing looks like "charge $49 a month" and turns out to be trials, upgrades halfway through a month, failed cards, refunds, tax and invoices. A hosted billing product handles those. Stripe Billing, for example, charges 0.7% of billing volume on its pay-as-you-go plan, on top of card processing at 2.9% + 30¢ per successful US card charge (Stripe, vendor pricing).

What you still build is the link between billing and your product: which plan unlocks which features, and what happens to a customer's account when a payment fails. Start with one or two plans. Pricing pages with five tiers are a guess you have to maintain.

Can you build a SaaS product without coding?

Yes, for a first version whose job is to win your first paying customers. No-code tools and AI app builders such as Lovable or Bolt can give you sign-up, a database and working screens in days. If you're still testing whether anyone will pay, that's the right tool, and you don't need to hire anyone.

The limits show up in the SaaS-specific rows of the table above. Many companies sharing one database, roles that differ per company, billing that changes mid-month: these are where generated apps tend to break, and quietly. The best-known example is CVE-2025-48757, where insufficient database row-level security in apps generated by Lovable let unauthenticated attackers read or write database tables. That's a tenant-isolation failure, the exact part that has to be right in SaaS.

Can you build a SaaS with Claude Code or other AI tools?

You can build much of it with AI coding tools, if a person decides what to build and reads what comes back. I use AI tools in my own work. They're fast at the parts that have been written a thousand times before: screens, forms, CRUD endpoints, tests for code that already exists.

Where they stop being enough:

• The data model. Which things exist, how they relate, and which belong to a tenant. A tool will happily build whatever you describe, including a model that can't support your second customer.
• Security you can't see from the screen. Veracode tested more than 100 language models on 80 coding tasks and found security flaws in about 45% of the generated code (Veracode, vendor research). The app works; the hole is invisible until someone looks for it.
• Billing and webhook edge cases. The happy path is easy. The card that fails on renewal day, the duplicate event, the refund after a downgrade are not.
• Changing live data. Database migrations on a system with paying customers, where a mistake can't be undone with another prompt.

If you've already built something with an AI tool and it's starting to fight you, I wrote a scorecard for that decision: rescue it, rebuild it, or keep prompting.

What tech stack should a SaaS MVP use?

Pick boring, widely used tools that your next engineer already knows. For NextMantra I used Next.js for the web app, NestJS for the API and PostgreSQL for the data, deployed on AWS with the infrastructure written as code. Infrastructure as code means the servers, databases and permissions are defined in files in your repository, so the whole setup can be rebuilt or reviewed rather than living in someone's memory.

The specific stack matters less than four habits: tenant isolation enforced by the database, automatic backups you've tested restoring, deploys anyone can repeat, and error tracking from day one. My default picks for each kind of product are in the best tech stack for an MVP in 2026. I go deeper on architecture choices on the engineering page.

What should be in version one, and what should wait?

Version one should do one job well for one type of customer, and be safe to put real company data in. Here's the cut I'd make for most B2B SaaS ideas.

Every item on the right is something a customer may well ask for. That's the point: let them ask, then build it for the one who's paying. The Jira-style onboarding SaaS story walks through a full cut like this, week by week.

How much does it cost and how long does it take?

A focused SaaS MVP is a 6–10 week build with one senior engineer, and my MVP builds start at $15,000. Multi-tenant B2B scopes with several roles and billing usually land above that starting point. To see roughly where yours lands, put your roles and integrations into the app cost calculator. Rather than repeat the numbers here, I broke them down in two posts: what an MVP costs, line by line, and how long an MVP takes, week by week.

Running costs at launch are small: hosting, a database, email sending, error tracking and payment fees. The expensive thing is never the servers at this stage. It's building features nobody pays for.

When should you not build a SaaS from scratch?

Don't build one when an existing tool does 80% of the job and you're the only customer. If you need the workflow for your own team, buy a tool and configure it. Don't build one before anyone has agreed to pay, either. And don't hire someone like me for version one if a no-code or AI-built prototype can win your first five customers. Spend that money once you know what they're paying for.

Build from scratch when the workflow is the product, when customers will trust you with their data, and when you've seen people pay for an ugly version. That's the point where tenancy, security and code you own start to matter more than speed.

What should you do this week?

• Write one sentence: "[type of company] pays us to [one job] because [what it costs them today]."
• List the activation steps from sign-up to first useful result. Aim for three.
• Go through the "cut from v1" column and move anything you'd planned into a later list.
• If you built a prototype with an AI tool, check whether one test customer can see another test customer's data. Try it with two accounts.

If you've got paying interest and need the version that's safe for real customer data, this is the kind of build I do end to end, with the repository and cloud accounts in your name from day one. Here's how I work.