How to build a SaaS product: a practical development guide

Short answer: to build a SaaS product, validate that a specific group of customers will pay for a specific outcome, then build a first version that has the SaaS foundations right from day one: every record belongs to a tenant, users belong to organisations with roles, plans map to features through entitlements, billing handles failure as well as success, and you have the tooling to onboard, support and observe customers. The features themselves can start small. The foundations are expensive to retrofit.

Most guides on this topic list the same steps: research the market, pick a tech stack, build an MVP, launch. Those steps are true but not very useful. This guide focuses on the decisions that are cheap to make at the start and painful to change later, how to plan the build in weeks and team shape, and how to recognise when SaaS is not the right model for your idea.

What makes software SaaS, not just hosted software

Software as a service is a delivery and business model, not a technology. AWS makes the point in its SaaS Lens: even when each customer gets dedicated infrastructure, a SaaS product still has shared identity, onboarding and operations for all of them. That is what separates SaaS from a managed service where every customer runs their own version with its own processes.

In practice, a SaaS product has these properties:

• One product version that every customer runs, updated continuously, rather than a different release per customer.
• Self-service or low-touch onboarding. A new customer can sign up, or be set up, without an engineer.
• Recurring revenue tied to plans, seats or usage, with upgrades, downgrades and cancellations handled by the system.
• Tenancy. The system knows which customer every piece of data belongs to and keeps customers apart.
• Operations as a product feature. Uptime, support, security and data protection are part of what customers pay for.

If your plan is to build one system for one organisation, you are building custom software, not SaaS, and that is often the better choice. Our guide to custom software versus off-the-shelf covers that decision.

Before code: decide what you are selling

The commercial model shapes the architecture more than most founders expect. Settle these questions before the first sprint, even if the answers are provisional.

• Who is the customer and who is the user? In B2B the buyer is an organisation and the users are its employees. In B2C they are usually the same person, but families, teams or clubs may share an account.
• What is the unit of value? Seats, active users, projects, locations, transactions, API calls or storage. Whatever you charge for, the system has to count it accurately and show it to the customer.
• How will customers buy? Self-serve card payments, invoiced annual contracts, a marketplace, or a mix. Enterprise contracts bring purchase orders, custom terms and security questionnaires.
• What differs between plans? Feature access, limits, support levels, data retention or isolation. Write this as a table now; it becomes your entitlements model.
• Where are your customers? Location drives data residency, tax on digital services, languages and the regulations you must meet.

Then validate the problem with real buyers before building much. Interviews, a clickable prototype, a concierge version run by hand, or pre-sales to a few design partners will tell you more than a polished product nobody asked for. Our article on scoping an MVP without wasting budget goes into how to cut the first release down to what proves the idea.

Choose a tenancy model

Tenancy is how you share or separate infrastructure and data between customers. Microsoft's guide to tenancy models describes isolation as a spectrum rather than a single switch, and that is the right way to think about it. AWS uses three names for the main patterns: silo, pool and bridge.

For most new products the pragmatic answer is a pooled model built so that it could become a bridge later: a tenant ID on every tenant-owned table, all queries scoped through one layer, and nothing that assumes there will only ever be one database. That keeps early costs low without closing the door on the enterprise customer who asks for their own database in year two.

Make isolation hard to get wrong

In a pooled model, the main risk is code that forgets to filter by tenant. The OWASP API Security Top 10 ranks broken object level authorisation first: an API that lets a logged-in user fetch someone else's record by changing an ID. In multi-tenant software that bug becomes a cross-customer data breach. Defend in layers:

• Resolve the tenant once per request from the authenticated session, never from a value the client sends, and pass it through a single data-access layer.
• Use database-level protection as a backstop. PostgreSQL row-level security denies access to rows unless a policy allows it. Note that table owners bypass it unless you force it, and superusers always bypass it, so the application should connect with a restricted role.
• Scope caches, file storage paths, search indexes and background jobs by tenant too. Leaks often happen outside the main database.
• Write automated tests that log in as one tenant and try to read, update and delete another tenant's data through every API. Run them on every change.

Identity, organisations and roles

A surprising number of SaaS products start with users and bolt on organisations later, which means migrating every record and rewriting permissions. Model it properly from the start, even if the first version only exposes part of it.

• Organisations (tenants) own the data; users belong to organisations. Allow one user to belong to several organisations; consultants, agencies and group companies need it.
• Invitations and membership: invite by email, accept, remove, transfer ownership. Decide what happens to a user's content when they leave.
• Roles and permissions: start with a few roles (owner, admin, member, perhaps read-only) defined in code, with permission checks in one place. Custom roles can come later.
• Authentication: email and password with multi-factor authentication, plus social login if your buyers expect it. Use a proven identity provider or library rather than writing password and session handling yourself.
• Enterprise identity: larger customers will ask for single sign-on through SAML or OpenID Connect, and automatic user provisioning through SCIM. You do not need these in the MVP, but your user model should not make them hard to add.

Billing, plans and entitlements

Billing is where many SaaS products accumulate their worst technical debt, because the happy path is easy and the edge cases arrive one support ticket at a time. Use a billing platform such as Stripe, Paddle or Chargebee rather than building subscription logic yourself, and keep a clear line between three concepts:

• Plans and prices live in the billing platform: what the customer pays, how often, in which currency.
• Entitlements live in your product: what a tenant may do, such as which features are on and what the limits are. Your code should check entitlements, never plan names, so you can change packaging without a release.
• Usage is what the tenant actually consumed. If you charge by usage, record it as an append-only ledger you can audit and reconcile, not a counter you overwrite.

Design the unhappy paths early. Cards fail, and billing platforms retry them on a schedule: Stripe's Smart Retries, for example, default to up to eight retries within two weeks for new accounts, and you choose whether a subscription is then cancelled, marked unpaid, left past due or paused. Your product must reflect each of those states: grace periods, read-only mode, data retention after cancellation, and what happens on reactivation. Handle upgrades and downgrades mid-cycle, trials that convert or expire, refunds, and webhook events that arrive late, twice or out of order.

Tax is part of billing. In the EU, VAT on digital services sold to consumers is generally due where the customer lives once cross-border sales pass an annual EUR 10,000 threshold, and the One Stop Shop lets a business declare that VAT through a single registration. Other regions have their own rules. Many early SaaS companies use a merchant of record, which sells on their behalf and handles tax, in exchange for a larger share of revenue. Take advice from an accountant before launch, not after the first audit.

Security and data protection from day one

B2B customers will send you security questionnaires long before you can afford a security team. The good news is that the basics are mostly decisions, not big projects, if you make them early.

• Tenant isolation and authorisation tests as described above.
• Encryption in transit everywhere and at rest for databases, backups and file storage, with secrets in a managed vault rather than in code or environment files on laptops.
• Least privilege: separate cloud accounts or projects for production, restricted database roles, and no shared admin logins.
• Audit logs that record who did what in each tenant: logins, permission changes, exports, deletions. Customers will ask for them, and you will need them during incidents.
• Backups you have restored, not just taken, with a tested process for restoring a single tenant's data.
• Data processing terms. Under the GDPR, when you process personal data for customers you act as their processor, which requires a contract covering instructions, security, sub-processors, and deletion or return of data at the end, as set out in Article 28. Keep an up-to-date list of your sub-processors.
• Data export and deletion: let tenants export their data and delete their account, and make sure deletion reaches backups and third parties within a stated period.

Larger buyers will eventually ask for an independent report such as SOC 2, an attestation by an independent auditor against the AICPA's trust services criteria covering security, availability, processing integrity, confidentiality and privacy, or for ISO/IEC 27001 certification. Neither is a launch requirement for most products, but building access control, logging, change management and backups properly from day one makes the audit far easier when it comes.

The control plane: the half of SaaS nobody demos

AWS's SaaS architecture fundamentals describe a SaaS system as two parts: the application your customers use, and a control plane that onboards, manages and observes tenants. Founders tend to fund the first and forget the second. Then the first customers arrive and every support request becomes a database query run by a developer.

• Tenant onboarding: sign-up or provisioning, default settings, sample data, and for silo tenants, automated infrastructure creation.
• An internal admin console: find a tenant, see its plan, usage, users and billing state, extend a trial, apply a credit, unlock an account.
• Safe support access: if staff can view a customer's account as that customer, the access must be permission-checked, time-limited, visible to the customer where appropriate, and recorded in the audit log.
• Per-tenant observability: logs, metrics and traces tagged with the tenant ID, so you can answer 'is it slow for everyone or just this customer?' in minutes.
• Feature flags per tenant: release a feature to design partners first, or switch something off for one customer without a deployment.
• Product analytics: activation, feature use and retention per tenant, which is what tells you whether the product is working as a business.

Your first ten customers will judge you less on features than on how quickly you fix what goes wrong. That speed comes from the control plane.

Architecture and tech stack choices

The best stack is usually the one your team knows well, running on managed services so a small team is not operating databases and queues by hand. The bigger decision is how you structure the system. Here is how the common options compare for a new SaaS product.

Whatever you choose, a few practices pay off immediately. Keep configuration out of code and environments as alike as possible, as the Twelve-Factor App recommends. Use infrastructure as code so a new environment, or a new silo tenant, is a command rather than a week of clicking. Run database migrations automatically and make them backwards compatible, because in SaaS every customer upgrades at the same moment. Our guide to DevOps services covers delivery pipelines in more depth.

A realistic build plan

Here is an illustrative plan for a B2B SaaS first release, such as a scheduling or workflow tool for small businesses, built by a small senior team: a product designer part-time, two or three full-stack engineers, and a senior engineer leading architecture, security and delivery. Timings are examples of how a plan is built, not a quote; your scope will change them.

That adds up to roughly four to six months for a focused first version, with phases overlapping where the team allows. It shrinks when the core workflow is simple or you use more off-the-shelf components, and it grows with integrations, mobile apps, complex permissions or regulatory requirements. To explore how different scopes and team shapes move an estimate, use our software cost calculator. If uncertainty is high, a time-and-materials or sprint-based model often fits better than a fixed price; see fixed price versus time and materials.

Build or buy each component

A small team should build what makes the product different and buy almost everything else. Good candidates to buy: identity and SSO, payments and subscriptions, email and notifications, product analytics, error tracking, feature flags and search. Good candidates to build: your core workflow, your data model, and anything that is part of why customers choose you. Revisit the decision when a bought component becomes a major cost or a real limitation, not before.

Running a SaaS product after launch

Launch is when the real work starts, because every customer now depends on the same system. Plan for these from the start:

• Release safely: small, frequent releases behind feature flags, automated tests in the pipeline, and a rollback you have practised.
• Migrate without downtime: schema changes in expand-and-contract steps so old and new code can run side by side during a deploy.
• Protect tenants from each other: rate limits per tenant, background job queues that one large tenant cannot monopolise, and alerts when a tenant's usage jumps.
• Measure reliability: define service level objectives for availability and response time, alert on them, and publish a status page.
• Budget for maintenance: dependency updates, security patches and infrastructure changes take steady time every month. Our maintenance and support guide explains how to plan for it.
• Watch unit costs: know your infrastructure and third-party cost per tenant, so pricing and the largest customers do not quietly erode margin.

When SaaS is the wrong model

SaaS is attractive because recurring revenue compounds, but it suits fewer ideas than its popularity suggests. Think twice in these cases:

• You have one large customer. Building for a single organisation is custom software; treat it that way and agree ownership and pricing accordingly.
• Each customer needs deep customisation. If every deal requires bespoke features, you are running a services business with a shared codebase, which is hard to maintain. Configuration, integrations and APIs can help, but only up to a point.
• Customers cannot put their data in a shared cloud. Some regulated or government buyers require on-premises or sovereign deployment. A single-tenant or installable product may fit better.
• A good off-the-shelf product already exists. If your idea is a slightly better version of a mature tool, competing on features is expensive. A plug-in, integration or vertical niche may be a better entry point.
• You cannot fund the operations. SaaS means support, uptime, security and billing every day. If nobody will own that after launch, the product will decay quickly.

How Authect approaches SaaS builds

When you talk to Authect, you talk to the founders who will build your product, never a salesperson. Every project is led by a senior engineer who makes the tenancy, security and billing decisions with you in the first weeks, because those are the ones that are expensive to reverse. We work in small teams with AI-accelerated delivery, and an engineer reviews every line that ships.

You own the code, infrastructure and designs from day one, so there is no lock-in if you later build your own team. We work as fixed-price projects when scope is clear, monthly sprints when it is still moving, and support and evolution after launch. Our storefront SaaS concept shows how we think about a multi-tenant product. If you are planning a SaaS product, talk to us before the architecture is set.