How to Build a SaaS Product From Scratch

“Build a SaaS from scratch” is usually searched by someone who has a wedge — a workflow they know too well — and a fear of wasting a year on the wrong architecture. The useful answer is a **build order**, not a list of languages.

This is that order: job, tenant model, identity, the core path, billing that matches how you actually charge, onboarding, then operations. Stack comes after those decisions. Cost sits in [custom software development cost in 2026](/blog/custom-software-development-cost-2026). The first-release cut is the rest of this article: one job a paying tenant can finish.

RootoverZero builds this class of product as [web applications](/services/web-applications) with a founder close to scope. If you are still deciding whether you need a product at all versus an internal tool, start with [custom software cost](/blog/custom-software-development-cost-2026) and [custom vs off-the-shelf](/blog/types-of-software-companies-and-who-to-hire).

The job, not the category

SaaS is software other companies pay to use on a recurring basis. That sentence hides the only question that matters on day one: **what job is complete when they would feel stupid going back to email?**

Write that job in one line. “A clinic coordinator can see tomorrow’s rooms, staff, and open slots without a shared spreadsheet.” If you cannot write it, you do not have a product. You have a theme.

Everything you add that does not serve that job is inventory you will maintain: screens, permissions, support replies, and billing edge cases.

Prerequisites before a repository

You need a decision-maker who will answer process questions twice a week. You need a first customer shape (even if they have not paid yet): industry, company size, who logs in. You need to know whether data is allowed to mingle across customers. That last answer is the tenancy decision, and it is cheaper to make now than in month nine.

You do not need a perfect specification. You need [discovery](/blog/how-rootoverzero-scopes-custom-software) honest enough that “shipped” has a meaning. Our [scoping approach](/blog/how-rootoverzero-scopes-custom-software) is the same for SaaS as for internal software; the difference is that SaaS also has strangers, invoices, and a clock that resets every month.

Step 1 — Draw the tenant

A tenant is the customer organization: one company, one clinic group, one shop. Users belong to a tenant. Data belongs to a tenant. If you skip this and store rows in a single pile with a `company_name` string, you will leak data or write a migration that feels like a product rewrite.

[Multi-tenant architecture](/blog/how-to-build-a-saas-product-from-scratch) explains the patterns. [Single-tenant vs multi-tenant](/blog/how-to-build-a-saas-product-from-scratch) is the commercial choice (isolation, enterprise procurement, ops cost). For a first SaaS, default to **logical multi-tenancy** (shared app, tenant key on every query) unless a regulated buyer has already told you they require a private instance.

The implementation rule: every query that returns business data filters by tenant. Every file sits in a tenant prefix. Every background job carries a tenant id. Forget one of those and you do not have a SaaS. You have a shared database with hope.

Step 2 — Identity that will survive year two

Start with email-and-password or a social login only if your buyers live there. Most B2B SaaS eventually needs invitations, roles, and someone who can disable a leaver without deleting history.

Do not build a custom identity product. Use a maintained auth service or a well-known library and put your effort into **roles that match the job**: owner, staff, read-only. Three roles beat twelve imaginary personas.

SSO (SAML/OIDC) is a procurement feature. If your first ten customers will not ask, do not let it block the core path. Record it as a later gate for [B2B SaaS cost](/blog/custom-software-development-cost-2026).

Step 3 — The core path, end to end

Build the smallest loop that completes the job:

A tenant exists. A user in that tenant can do the job. The result is stored correctly. Another user in the same tenant can see it. A user in a different tenant cannot.

That is the MVP test. Dashboards, public marketing site, and a changelog can wait. A [website](/services/websites) that explains the product is useful for acquisition; it is not the SaaS. Mixing brochure pages into the app repo without a clear public/private split is how you ship a slow marketing site with a login bolted on. See [web app vs website](/blog/web-app-vs-website).

Step 4 — Billing that matches how you charge

Billing is not a Stripe badge on the pricing page. It is a state machine: trial, active, past_due, canceled, plus what the app does in each state.

If you charge per seat, the app must know who is a billable seat. If you charge for usage, you must meter something you can defend in a dispute. If you charge a flat plan, you still need a source of truth for “this tenant is allowed to use the product.”

Architecture notes live in [SaaS subscription billing](/blog/how-to-build-a-saas-product-from-scratch) and [subscription management](/blog/how-to-build-a-saas-product-from-scratch). Practical rules for a first version:

One provider (commonly Stripe) as system of record for money. Webhooks as the way the app learns about payment events — not a nightly CSV. A grace period you can explain to a human, not an instant lockout that nukes a clinic mid-day. No card data on your servers.

Pricing *model* (flat, per-user, usage) is a different article: [SaaS pricing models](/blog/how-to-build-a-saas-product-from-scratch). Pick one for the MVP. Dual models double support.

Step 5 — Onboarding as a product surface

The first session decides churn more often than a missing feature. If the empty state is a blank table, people bounce.

For B2B, onboarding is usually: invite the team, import or skip data, complete one real job. For consumer-ish SaaS it may be a sample project. Either way, measure whether the job happened, not whether they clicked “Next.”

Churn math belongs in [SaaS churn calculator](/blog/how-to-build-a-saas-product-from-scratch). You do not need a data team on day one. You need to know if week-one tenants complete the job.

Step 6 — Operations: logs, backups, a person

SaaS is an operations business wearing a product costume. Budget for:

Staging that is not production with a different URL guessed by customers Backups you have restored once Error reporting with tenant id on the event A way to freeze a tenant that is abusing the system A written path for “we need to delete this company’s data”

[SaaS security checklist](/blog/software-that-holds-up) is the companion. [SaaS maintenance cost](/blog/improving-software-you-already-have) is the money after launch. [Software that holds up](/blog/software-that-holds-up) is the quality bar.

APIs: when they belong in v1

If the product *is* an API, you are building a platform and the first customer is a developer. That is a different first release: keys, versioning, docs, idempotency. Read [SaaS API architecture](/blog/how-to-build-a-saas-product-from-scratch).

If the product is a UI for operations people, do not postpone the core path to “build a public API.” An internal API between your web app and your backend is enough. Public API is a distribution channel you can add when someone will pay for it.

Common mistakes

**Starting with multi-region, Kubernetes, and a mesh.** You do not have a traffic problem. You have a clarity problem.

**Skipping tenancy because “we’ll add it.”** You will add it as a rewrite.

**Building five integrations before one job works.** Integrations are where time goes to die. Pick the one system of record your buyer already trusts — often accounting or identity — and delay the rest. [Stripe and QuickBooks as the spine](/blog/buy-stripe-and-quickbooks-build-the-workflow) is the same idea for non-SaaS ops; for SaaS, the spine is your tenant + billing + job.

**Treating the marketing site as the product.** SEO pages do not retain tenants.

**Hiring a bench that never uses the app.** Founder-led delivery exists because SaaS scope drifts weekly. See [founder-led delivery](/blog/founder-led-delivery) and [how to choose a SaaS development company](/blog/how-to-choose-a-software-development-company-2026).

A realistic first-release checklist

Tenant model written down (shared app vs private instance) Auth with invite + three roles Core job completable by two users in one tenant Isolation test: tenant B cannot read tenant A Billing states wired, including failed payment Empty-state onboarding that reaches the job Backups and error reporting A support mailbox that is not a founder’s personal spam folder

If a vendor demo cannot show isolation and a failed-payment path, you are looking at a prototype.

What to build later on purpose

Usage analytics beyond “did they finish the job,” marketplaces, partner portals, SSO, custom domains, and a public API are later. So is a native mobile app unless the job is inherently on a phone. Mobile cost is a separate cluster: [mobile app development cost](/blog/custom-software-development-cost-2026).

How long this takes

Calendar time depends on whether the job is a known workflow or a science project. A tight MVP can be weeks to a few months with a small team that has access to a real user. A marketplace-shaped SaaS is not an MVP; it is two products and a trust problem. [Timeline](/blog/how-rootoverzero-scopes-custom-software) and [estimation](/blog/custom-software-development-cost-2026) apply; add billing and tenancy to the work breakdown.

When not to build SaaS

If only one company will ever use it, you want [custom software](/services/custom-software), not a multi-tenant product. If a category giant already encodes your objects, buy it and build the missing workflow. If you cannot name a buyer who feels the pain weekly, you are funding a hobby with production costs.

CTA

If the job is clear and you need a team that will not confuse a pricing page with a product, [start onboarding](/onboarding) or talk through [web application work](/services/web-applications). Bring the one-line job, the likely first tenant, and the budget band you can actually spend.

FAQ

Do I need an LLC and a privacy policy before writing code?

You need a legal shape before you take payment and store other companies’ data. You do not need to freeze engineering until the lawyer’s last comma. Parallelize: core path in a private environment, policy work before the first paid tenant.

Should we start on no-code?

No-code is fine for proving the job with one friendly customer. It is a poor home for tenancy, billing states, and audit. Plan the exit before the first paid invoice if you go that route.

Native app or web app first?

If the work happens at a desk, start on the web. If the work happens with wet hands in a kitchen or on a shop floor, you may need mobile earlier — still with a real backend. Do not ship two native clients before one tenant model.

How do we pick a tech stack?

Pick a stack your team can operate at 2 a.m. Boring and known beats fashionable. Shopify-specific products are a different stack conversation: [Shopify app tech stack](/blog/how-to-build-a-shopify-app-from-scratch).