The SaaS Product Development Guide

Building a SaaS product looks deceptively similar to building a website. It is not. A website serves the same content to everyone; a SaaS product holds many customers’ data in the same system and has to guarantee that none of them ever sees another’s. That single requirement drives the architecture, the security work, the compliance burden, the running costs, and a large share of the engineering time.

Most SaaS advice skips over this. It jumps to growth benchmarks and funding milestones, quoting retention and payback figures that turn out, on inspection, to come from surveys of wildly different company sizes with incompatible definitions. Useful for a pitch deck; considerably less useful when you are trying to decide whether every customer gets their own database.

This guide covers the decisions that actually determine whether a SaaS product works: how tenants are isolated, what belongs in a first version, how to price it, what security and data protection genuinely require, and what it costs. Where something is a factual or legal claim, it links to a primary source. Where a number is contested or unverifiable, this guide says so rather than repeating it.

What actually makes it SaaS

Software-as-a-service means customers access shared, centrally operated software over the internet, on a subscription, without running it themselves. The distinction that matters commercially is between genuine SaaS and hosted software wearing a subscription badge.

Plenty of profitable businesses run the second model deliberately. The mistake is charging SaaS-style subscription prices while carrying per-customer infrastructure and maintenance costs — the margin assumption quietly stops holding somewhere around the tenth customer.

Is SaaS the right model for your idea?

SaaS suits problems where many organisations need broadly the same capability and will accept broadly the same solution. It suits them much less where every customer needs the workflow bent to their own process.

Reasonable signals that SaaS fits:

• The problem is recurring, not a one-off project.
• Different customers would use something close to the same feature set.
• The value is ongoing, which justifies an ongoing subscription.
• Data accumulates over time, which makes the product harder to leave.
• You can reach enough customers to make shared infrastructure pay off.

Signals it may not:

• Every prospective customer describes a materially different process.
• The work is inherently project-shaped, with a defined end.
• The realistic customer count is small enough that per-customer builds cost less than a shared platform.
• Customers will not accept their data sitting on shared infrastructure — a constraint worth confirming before you design around it, not after.

The multi-tenancy decision

This is the single most consequential technical decision in a SaaS build, and it is far more than a database schema question. Microsoft’s Azure Architecture Center makes an important point in its guidance on tenancy models: isolation is not a binary choice but a spectrum, running from “shared nothing” to “shared everything” — and different layers of the same product can sit at different points on it.

It also stresses that choosing a tenancy model “isn’t only a technical decision. It’s also a commercial decision”, because it determines your cost per customer, what compliance promises you can make, and how far you can scale.

The common models

The noisy neighbour problem

On shared infrastructure, one customer’s heavy usage can degrade performance for everyone else. Microsoft’s guidance is explicit that if a large tenant runs an expensive query or operation, it can affect other tenants. Horizontal partitioning — a shared application tier with separate databases — is named specifically as a way to mitigate this when the database is where the load concentrates.

What this means in practice

For most new products, fully multitenant is the right starting point: it is far cheaper, and the alternative means operating a growing fleet of deployments before you have proven anyone wants the product. The risks are real but manageable if tenant isolation is enforced deliberately — at the data-access layer, not by remembering to add a filter to each query — and tested as a first-class concern.

The decision worth making early is not which model to use forever, but whether your codebase could ever support a dedicated deployment for a large or regulated customer. Retrofitting that later is expensive. Microsoft’s note on vertical partitioning applies directly: the codebase has to be designed to support both, and you need a plan for migrating a customer from shared to dedicated infrastructure.

Scoping a first version that can actually ship

The most common reason a SaaS build stalls is not technical difficulty. It is scope: a first version defined as everything the product might eventually do, which takes so long to build that the assumptions behind it expire before launch.

A first version has to include some things that feel unglamorous:

• Authentication, and an account model that reflects how customers are actually organised — usually organisations containing users, not just users.
• Roles and permissions, even if only two roles exist at launch.
• Tenant isolation enforced structurally, so a missing filter cannot expose another customer's data.
• Billing and subscription handling, including failed payments and cancellation.
• Onboarding — the path from signup to first useful outcome.
• Audit logging and basic observability, so you can answer 'what happened to this customer's data' when asked.
• Backups, and a restore procedure someone has actually tested.

What can usually wait: advanced reporting, an integrations marketplace, granular custom permissions, a public API, white-labelling, and multi-currency billing. Each is real work, and none of it is what determines whether the core promise holds up.

The useful test for a first version is whether a real customer can sign up, get the core job done, and pay for it — without anyone on your team manually intervening. Anything that does not serve that sentence is a candidate for the second release.

Pricing, and the pressure on per-seat

Pricing is a product decision, not a spreadsheet exercise done at the end. It determines who your customers are, what they expect, and whether your unit economics work.

The traditional default — a monthly fee per user seat — is under genuine pressure, because AI features break the assumption it rests on. Per-seat pricing assumes people are the unit of production. When software performs work autonomously, customer value can rise while the number of people logging in falls, which makes seats an increasingly poor proxy for value delivered.

You will find plenty of confident percentages describing how far the market has already moved away from seats. We are deliberately not quoting them: the figures we found varied substantially between sources, several came from vendors selling monetisation tooling, and the more credible surveys sit behind access controls that make the methodology hard to inspect. The structural argument does not need a statistic to stand up — if software does the work, charging per human who can log in measures the wrong thing.

What is worth doing is checking the current state of pricing among your own competitors and adjacent products, which is observable, free, and specific to your market in a way that an industry median never is.

The practical warning for any product with AI features: your costs are now partly variable and tied to usage. A flat unlimited plan can be sold at a loss to exactly the customers who use it most, and the problem does not surface until they have scaled up. If usage drives cost, something in the pricing has to track usage.

Security and compliance

For a B2B SaaS product, security is not only an engineering concern — it is a sales blocker. Above a certain customer size, procurement will ask for evidence, and “we take security seriously” is not evidence.

SOC 2 and ISO 27001

The two frameworks buyers most often ask about serve different purposes. SOC 2 is an attestation report produced by a CPA firm under AICPA standards, assessed against the Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only category required in every engagement; the others are included based on what you commit to customers. ISO/IEC 27001 is an internationally recognised, certifiable standard for an information security management system.

The distinction worth knowing before you commit budget is between the two SOC 2 report types. A Type I report assesses whether controls are suitably designed at a point in time. A Type II report assesses whether they operated effectively across a period — typically six to twelve months. Buyers who care usually want Type II, which means the controls have to be running properly for months before the report exists. That is a lead time, not a purchase.

What to build in from the start

• Encryption in transit and at rest, as a default rather than a feature.
• Role-based access control, with least privilege applied to your own team as well as customers.
• Audit logs covering who accessed what, and when.
• Tested, monitored backups with a known restore time.
• Dependency and vulnerability scanning in the deployment pipeline.
• A documented process for handling a security incident, written before you need it.

None of this is exotic, and all of it is dramatically cheaper to build in than to retrofit under the deadline of a customer’s security review.

Data protection obligations

If your product handles personal data of people in the EU or UK, the GDPR applies regardless of where your company is based. For most SaaS businesses the important framing is that your customer is the data controller and you are the processor, acting on their instructions.

Article 28 sets out what that relationship requires in a contract. Among other things, the processor must:

• Process personal data only on documented instructions from the controller.
• Ensure people authorised to process the data are bound by confidentiality.
• Implement the security measures required by Article 32.
• Assist the controller in responding to data subject rights requests.
• Delete or return the data at the end of the engagement.
• Make available the information needed to demonstrate compliance, and allow audits.

Two practical consequences are routinely missed. First, sub-processors — your hosting provider, your email service, any AI API you call — require authorisation from the controller, and you remain fully liable to your customer for their failures. Maintain an accurate sub-processor list and a way to notify customers when it changes. Second, “delete or return the data” means deletion has to actually work, including in backups, on a defined timeline. That is an engineering requirement with a legal deadline attached, and it is much easier to design in than to add later.

AI features and the EU AI Act

Adding AI features to a SaaS product is now close to standard, and it brings a regulatory dimension that did not exist a few years ago. The EU AI Act entered into force on 1 August 2024 and applies in stages: the prohibitions on unacceptable-risk practices applied from 2 February 2025, and obligations on general-purpose AI model providers from 2 August 2025. The full implementation timeline runs to the end of the decade.

This is an area where outdated guidance is actively misleading, because the timeline changed in 2026. The so-called AI Omnibus — Regulation (EU) 2026/1744 — was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026, deliberately fast-tracked to land before the original August 2026 deadline. It deferred the high-risk obligations for stand-alone Annex III systems from 2 August 2026 to 2 December 2027, and for AI embedded in regulated products under Annex I to 2 August 2028.

What did not move is as important. The Article 50 transparency duties — including telling people when they are interacting with an AI system — still applied from 2 August 2026, and the prohibitions and general-purpose AI obligations already in force were unaffected. So a product that assumed everything slid to 2027 would be wrong about the obligation most likely to apply to an ordinary SaaS product.

For most business SaaS products, which are not high-risk systems under the Act, the practical requirements are modest: be clear with users when they are interacting with AI or seeing AI-generated content, know which models and providers sit in your stack, and keep that documentation current. The heavier obligations attach to specific high-risk categories, and if you might fall into one — recruitment, credit, education, essential services — that is worth confirming with a qualified adviser rather than a blog post, this one included.

Metrics, and the benchmark noise problem

A handful of metrics genuinely tell you whether a SaaS business is working. It is worth understanding what they measure before worrying about what number is good.

On benchmarks, a warning. Published SaaS benchmark figures vary enormously — often by a factor of two or more for the same metric — because samples differ in company stage, size, market, and definition. Whether expansion revenue counts, whether churn is monthly or annual, and whether the sample is venture-backed all move the number substantially. Several widely circulated figures also come from vendors selling to the audience being surveyed.

The useful practice is to treat any benchmark as valid only if you can see the sample size, period, and definitions behind it, and to compare your business against its own trend rather than someone else’s median. Your churn moving from 4% to 2% is a fact about your business. Whether 3% is “good” depends on a dozen things the benchmark does not know.

The same scepticism applies to the widely repeated claim that 90% of startups fail. That figure has been traced back to a misreading of a 1975 business-failure report and does not hold up; credible estimates vary substantially depending on how “startup” and “failure” are defined. It is quoted far more often than it is sourced.

What it costs and how long it takes

Any specific figure quoted without knowing your requirements is marketing. What can be said honestly is where the cost actually goes, because founders routinely budget for the build and not the rest.

• The build itself — usually the part that gets estimated.
• Infrastructure, which starts small and grows with usage.
• Third-party services: payments, email, monitoring, error tracking, and any AI APIs.
• Security and compliance work, including audit fees if you pursue SOC 2 or ISO 27001.
• Ongoing maintenance: dependency updates, security patches, and platform changes you did not choose.
• Support, which is a real operational cost from the first paying customer.

On timelines, the honest answer is that a focused first version is typically a matter of months rather than weeks, and that the range is wide enough that anyone quoting a duration before understanding the requirements is guessing. What should be non-negotiable is that you receive a specific scope, timeline, and cost before work begins, rather than an open-ended arrangement.

One structural point worth internalising: a SaaS product is not a project that finishes. It is a system that runs. Budgeting for the launch and not for the operation is the most common financial mistake in this category.

Mistakes worth avoiding

• Deferring the tenancy decision, then discovering the data model cannot support an isolated deployment for a large customer.
• Enforcing tenant separation with per-query filters that one forgotten WHERE clause can defeat.
• Scoping a first release around every requested feature rather than the one job customers will pay for.
• Selling flat unlimited plans on a product whose AI costs scale with usage.
• Treating SOC 2 as a purchase rather than a period of operating controls that a Type II report can then attest to.
• Signing enterprise data protection terms without a working data deletion path, including backups.
• Building compliance plans on AI Act deadlines that the July 2026 Omnibus changed.
• Benchmarking against published medians without checking the sample or definitions behind them.
• Budgeting for the build and not for infrastructure, support, and maintenance.

Building in-house or hiring out

A SaaS product needs product thinking, interface design, backend and frontend engineering, infrastructure, security, and someone who will still be maintaining it in two years. Few early teams have all of that, and the parts most often missing are the least visible: tenancy design, security architecture, and operational readiness.

If you are evaluating a development partner, the questions that separate substance from a sales process are fairly specific:

• Which tenancy model would you recommend for this product, and why that one?
• How will tenant isolation be enforced — and how will it be tested?
• What is in the first release, and what have you deliberately left out?
• What will it cost to run per month at ten customers, and at a hundred?
• Who owns the code and the infrastructure accounts if we part ways?
• What happens after launch — who patches it, monitors it, and responds when it breaks at 2am?

Vague answers to the last two are the ones that cost the most later. Code ownership and post-launch responsibility are commercial terms, and they belong in the agreement rather than in an assumption.

Frequently asked questions

Final thoughts

The hard parts of building a SaaS product are rarely the ones that appear in the pitch. Deciding how tenants are isolated, keeping that isolation true as the codebase grows, pricing something whose costs move with usage, and being able to answer a security questionnaire without inventing an answer — these determine whether a product can carry real customers, and none of them are visible in a demo.

They are also the parts that get more expensive the longer they are deferred. Tenancy, data deletion, audit logging, and access control are cheap to design in at the start and painful to retrofit under a customer’s deadline. A first version that does less but handles those properly is worth considerably more than a broad feature set on foundations that cannot take weight.

And as with any fast-moving field, be careful what you take as fact. In the course of researching this guide, the most widely repeated startup statistic turned out to be a misread report from 1975, the AI Act deadlines most articles cite were changed by a regulation published in July 2026, and benchmark figures for the same metric differed by more than double between sources. Checking where a claim comes from, before building a plan on it, remains the cheapest safeguard available.