SaaS development life cycle: stages, gates and deployment

A stage is finished when a measurable exit criterion is met, not when its activities have been performed. The right gates, durations and compliance evidence depend on your tenancy model, your regulatory exposure and whether you sell to enterprises or to self-serve users.

SaaS development life cycle in short: Stages, gates, loop

Multi-tenant architecture, subscription billing and usage metering, and the CI/CD pipeline set the shape of the SaaS development life cycle, and each is expensive to reverse once customers are live.

Every release reaches all tenants at once, so each stage ends at an exit gate and usage data feeds the next cycle. From our SaaS builds, we recommend fixing tenancy, billing model and compliance scope during planning, because live tenants make all three costly to change. A single-customer internal tool or a fixed-scope custom build can run a lighter cycle.

SaaS development life cycle stages at a glance

The SaaS development life cycle has seven stages, and each should end at a measurable exit criterion before the next one starts. The table pairs every stage with its goal, key decisions, exit gate, duration, and the mistake teams make most often.

Durations are our judgement for a mid-size product. The exit thresholds are illustrative targets, not benchmarks.

Three terms in the table need a definition. An error budget is the unreliability a service level objective (SLO) permits over a window; once it is spent, feature work yields to reliability work.

Expand and contract splits a breaking schema change into additive and removal releases (detailed in the deployment section). A SOC 2 Type II observation window is the period over which an auditor tests that controls operate; it cannot start until the controls exist, so stage 5 is where the clock should begin.

How the SaaS development life cycle differs from the traditional SDLC

The SaaS development life cycle differs from the traditional SDLC because one team ships, operates and bills for a single live product that every customer uses at once. Installed software ends its cycle at release. A SaaS cycle continues into operation, where uptime, billing accuracy and upgrade safety are part of the product.

The differences side by side:

Tenancy is the one architectural choice that belongs in this comparison, because multi-tenant architecture forces every later stage to treat a release as an event affecting all customers. Decide the isolation model at planning, since changing it after launch means migrating live data. Our SaaS architecture guide covers the models in depth.

Billing moves from the sales team into the codebase. Plan changes, proration, usage events and invoicing run as product features, so they need the same tests, idempotency guarantees and release gates as anything else. Metering errors reach customers as wrong invoices.

Google's SRE book describes using the error budget to decide when to ship and when to stabilize. We recommend setting each SLO stricter than the contractual SLA, so the budget is spent before service credits become payable.

This comparison assumes a multi-tenant, vendor-hosted product. Single-tenant or customer-hosted deployments keep some installed-software traits, such as customer-controlled upgrade windows. Our SaaS development guide covers the build process itself, and our SaaS development services cover the whole cycle when you want a partner to run it.

How do you validate a SaaS idea before building?

Validate a SaaS idea by writing a go/no-go gate and a pricing-metric hypothesis before the first commit, then testing both with target accounts. Research on the market, competitors and customer needs feeds the gate, and the gate decides whether the build starts.

The gate is a written, dated threshold agreed before the first interview. An illustrative example, not a benchmark: go if 5 of 15 target accounts sign a paid pilot or pay a refundable deposit within six weeks, and otherwise narrow the segment or stop. Paid commitment counts as evidence, while interview enthusiasm costs the customer nothing.

The pricing-metric hypothesis names the unit you will charge for, such as seat, workspace, API call or processed document. Show a price sheet in the same conversations.

A good metric rises with the value the customer receives, which is what lets net revenue retention exceed 100% through expansion. It must also be countable: a usage-based metric needs usage metering per tenant, so confirm early that the event can feed subscription billing later.

Run the validation in four steps:

1. Define the activation event (for example, first report shared with a colleague) and set a target activation rate for pilot accounts.
2. Instrument a clickable prototype or a concierge pilot with product analytics, so activation is measured from day one.
3. Quote two or three price points on the chosen metric and record which one each account accepts.
4. Write the kill criteria: which result sends the team back to segment selection.

Prototype and pilot work like this fits inside product design, and its output is what planning inherits: accounts that reached the activation event and accepted a price.

One caveat. In enterprise segments with long procurement cycles, a deposit inside six weeks is often unrealistic. Substitute a signed letter of intent that names a budget owner and a start date, and extend the window accordingly.

Which decisions must be made at planning?

Planning must fix four decisions that get expensive after launch: scope, multi-tenant architecture, compliance scope, and subscription billing and usage metering. Write scope as a one-page document with goals, target accounts, a named competitor set and an explicit out-of-scope list, so the build starts from a predictable boundary.

The multi-tenant architecture choice (shared schema, schema per tenant, or database per tenant) sets how isolation, tenant-by-tenant rollout and per-tenant restore work. Changing it on a live product means migrating every tenant's data with the old and new models running in parallel. Choose against your most demanding expected customer.

The four decisions side by side. The cost ratings are our judgement, not a benchmark:

For compliance, Article 25(1) of the GDPR requires data protection measures "both at the time of the determination of the means for processing and at the time of the processing itself". Article 25(2) extends the default to the amount of data collected and the period of storage.

GDPR data protection by design therefore means retention rules and deletion paths exist before the first release, because retrofitting deletion across backups and analytics stores is slow.

ISO/IEC 27001 works differently: you define the scope of the information security management system. A narrow first scope is cheaper, but each system added later brings its own risk assessment and controls. If buyers will ask for SOC 2 Type II or ISO certification within a year, scope the systems that hold customer data now.

Subscription billing and usage metering carry the pricing-metric hypothesis from validation into code. Usage you never recorded cannot be backfilled, so emit metering events from the first release even if you bill flat seats. Moving from seats to usage later changes entitlements, invoicing and revenue reporting at once.

These rules assume you process EU personal data and sell to businesses that audit vendors. An internal tool or a single-customer product can defer certification, but not tenancy. Money-side detail sits in SaaS development costs.

Design and prototyping: Test onboarding before engineering starts

Test onboarding on a clickable prototype before engineering starts, and score it against the activation event your product analytics will measure after launch. Activation rate is the first number to move in a SaaS product, and net revenue retention follows months later; a flaw found in a prototype takes a day to fix, while the same flaw in shipped code takes a sprint.

Define the activation event during planning: the single action that predicts a retained account, such as a first report shared or a first teammate invited. The test then measures whether a new user reaches that event unaided.

A test script that fits a half-day session:

1. Recruit five to eight people from your target accounts, including at least one admin and one end user.
2. Give a scenario with no instructions: "You just started a trial. Get your team's first project running."
3. Stay silent and record time to the activation event, wrong turns, and every moment a participant asks for help.
4. Repeat steps 2 and 3 for the core workflow, the task users perform every week.
5. Close with one question: "How would you describe what this does to a colleague?"

An illustrative pass threshold, not a benchmark: at least four of five participants reach the activation event unaided within ten minutes, and no two abandon at the same screen. Calibrate the time limit to your product. An enterprise tool with SSO setup and data import needs a longer one.

Five to eight sessions find blocking problems, and they cannot predict conversion. Fix what failed, retest, and start the build only once the flow passes. Visual polish comes after that, using the patterns in our SaaS UI design guide. If your team lacks research capacity, product design support can run the sessions.

Build stage: Trunk-based development and the MVP slice

Trunk-based development, where engineers merge small changes into main at least daily behind feature flags, is the branching model we recommend for a SaaS build, because every merge can reach every tenant. Keep branches short-lived, under two days, hiding unfinished work behind feature flags so progressive delivery (rollout by percentage or tenant cohort) separates deploying code from releasing it.

Keep infrastructure as code (Terraform or Pulumi) in the same repository and pipeline, so every environment is reproducible. Framework choice is covered in our SaaS development framework guide.

The MVP slice is the thinnest vertical path a paying tenant can complete: sign-up, tenant provisioning, one core workflow, one plan, one invoice. Run subscription billing and usage metering as a workstream with its own owner from the first sprint. Adding plans, entitlements and usage events after launch means migrating live customer data.

Three failure modes recur in this stage, and each gives an early warning:

For metering, give every usage event an idempotency key built from the tenant ID and the source event ID. Assume at-least-once delivery, and deduplicate on that key where usage is aggregated. Reconcile the raw event log against billed usage before the first real invoice goes out.

For flags, require an owner, an expiry date and a removal ticket at creation. Fail the CI pipeline when a flag passes its expiry. Permanent entitlement flags belong in the billing model, not in the release-flag set.

This discipline has limits. A team of two or three engineers with one environment can use a hosted billing provider's built-in metering and a handful of flags managed by convention. The custom pipeline described above pays off once usage-based pricing or several enterprise plans enter the MVP.

Testing stage: From tenant isolation tests to closed beta

Tenant isolation testing belongs in the CI/CD pipeline from the first merge, and the closed beta ends only when written exit criteria hold.

NIST's Secure Software Development Framework (SP 800-218) gives the pipeline its structure. Practice PW.7 covers code review and analysis, PW.8 covers testing executable code, and RV.1 covers identifying vulnerabilities after release. Map each practice to a pipeline stage and keep what the stage produces.

The test matrix, with the evidence each run leaves behind:

Seed two tenants with overlapping data and expect a 403 or 404 on every cross-tenant request. TLS checks cover minimum protocol version and certificate expiry, since encryption in transit is what stops interception of traffic to and from the application.

A SOC 2 Type II report tests whether controls operated throughout an observation window, the audited period, usually months. Retained pipeline logs show a control ran on every change, which a one-off test cannot. Article 32(1)(d) of the GDPR likewise calls for a process for regularly testing and evaluating security measures.

We recommend a closed beta of roughly 4-8 weeks with a handful of design-partner tenants (our judgement, not a benchmark). The exit gate:

1. Zero open high-severity security findings.
2. The cross-tenant suite green on every merge during the beta.
3. SLOs met across the whole window with the error budget unspent. An illustrative target is 99.5% availability over 30 days.
4. A restore from backup tested end to end.
5. Metered usage reconciled against invoices for every beta tenant.

These rules assume a single production environment. Regulated buyers may add penetration tests by an external party before the gate closes.

What does a SaaS deployment process look like?

A SaaS deployment process promotes one build through staging to production, separates deploy from release with feature flags, and ships schema changes in backward-compatible steps.

The CI/CD pipeline builds a single immutable artifact and promotes it unchanged from staging to production, so only configuration differs between environments. Blue-green deployment keeps two production fleets and switches traffic between them, which gives fast rollback for stateless services.

Canary deployment sends a small traffic share to the new version first. Feature flags add progressive delivery: code ships dark, then turns on per tenant cohort.

Why staging hides migration failures

A staging environment with small, evenly spread data passes migrations that production will fail. A backfill that takes milliseconds on a staging table can hold locks for minutes on the largest tenant's production table. Tenant skew, long-running transactions, and replica lag only appear at production shape.

We recommend a staging database restored from masked production data, with the largest tenants represented, and a timed dry run of every migration against it. Confirm the masking meets your data-protection policy before copying anything.

The expand-and-contract sequence

Expand and contract is a migration pattern that splits one breaking schema change into additive and removal steps, so the old and new application versions can run against the same database at once. Each step ships as its own release, and only the final drop is irreversible.

1. Expand: add the new nullable column or table. Nothing reads it yet.
2. Dual write: the application writes to both old and new structures.
3. Backfill: copy historical rows in small, throttled, idempotent batches that can resume after a failure.
4. Switch reads: move reads to the new structure behind a flag, one tenant cohort at a time.
5. Contract: stop writing the old structure, wait out an observation window (the agreed period of watching production metrics before the next step), then drop it in a separate release.

Until step 5, rollback means flipping a flag, because the old structure is still current.

Tenant-cohort rollout with rollback triggers

Roll out by cohort, ordered by blast radius, and write the rollback triggers down before the first flag flips. Tie them to the SLO, so a cohort that burns error budget faster than planned pauses the rollout.

The thresholds below are illustrative starting points, not benchmarks. Tune them to your own baseline.

Rollback is a flag flip or a traffic switch back to the previous blue-green fleet, never a rebuilt artifact. Teams running this on cloud infrastructure need the pipeline, flag service, and observability wired together before cohort 1; our cloud application development work covers that setup.

Operate: Observability, SLOs and error budgets as release gates

SLOs and error budgets turn observability data into a release gate: when the budget is spent, feature releases stop until reliability recovers.

An SLO is a reliability target for a user-facing behavior, such as successful checkout requests. As an illustrative example, a 99.9% availability SLO over 30 days leaves about 43 minutes of failure. Google's SRE book uses this budget to balance reliability work against feature velocity.

Instrument services with OpenTelemetry so traces, metrics, and logs share one vendor-neutral format. Tag each with a tenant identifier, which lets you slice SLIs per tenant and spot one customer burning the budget before the aggregate number moves.

The decision rule works best as a written error budget policy that product and engineering agree on before the first incident. The thresholds below are illustrative; tune them to your SLO and release cadence.

Every incident that consumes budget gets a blameless review. The review's action items enter the backlog ahead of new features while the budget is spent, so incident review feeds the roadmap directly. The review also asks which flag, test, or alert would have caught the failure earlier.

The DORA metrics pair throughput (deployment frequency, lead time for changes) with stability (change failure rate, failed deployment recovery time). Read them next to the budget: rising deployment frequency with a draining budget means the pipeline is shipping risk faster than the product can absorb it. Hosting and runtime choices for this stage sit with cloud application development.

This gate has limits. Before product-market fit, traffic is often too thin for a percentile SLO to mean anything, so start with a plain availability target and a short incident log. Move to per-journey SLOs once volume makes the numbers stable.

Iterate and scale: Analytics, activation, churn and the roadmap loop

Product analytics ranks roadmap items by three signals, and we recommend acting on a DORA delivery stall first, a churn cohort second and an activation drop third. Every fix for the other two signals ships through the pipeline, so a degraded pipeline slows all of them.

Activation rate is the share of new accounts that reach a first-value event, such as a first report or an accepted invite, within a fixed observation window after signup. Net revenue retention (NRR) is the recurring revenue a cohort generates today divided by its revenue at the start, counting expansion, contraction and churn.

The decision rule, in priority order:

As an illustrative trigger, not a benchmark, treat two consecutive release cycles of rising change failure rate or recovery time, or a spent error budget from the Operate stage, as the signal to stop shipping features.

A platform sprint ends when those metrics return to the trend you had before the stall. Feature work then resumes, and the churn and activation items wait in the queue in the order above.

Cohort reading needs volume. With only a few dozen new accounts a month (an illustrative threshold), activation and churn percentages swing on single accounts, so pair them with customer interviews before reordering the roadmap.

Customer lifecycle management is a separate discipline. The recurring problems teams hit while scaling are covered in SaaS development challenges.

SaaS product lifecycle stages: Engineering priorities from launch to decline

SaaS product lifecycle stages each shift engineering priorities: launch fixes tenancy and billing foundations, growth hardens delivery, maturity trims cost and risk, and decline ends in a controlled sunset.

The priorities per phase, side by side:

Error budgets and the SOC 2 observation window both start accumulating at launch, so wire them in early.

Retirement needs its own plan, and we recommend this order:

1. Publish the sunset policy. Close new signups first, then set a notice period longer than your longest contract renewal cycle, and stop billing at the shutdown date.
2. Freeze the product. Ship security patches only, and keep the SLOs on read and export paths until the last tenant leaves.
3. Provide data export. Offer a self-serve export in open formats (CSV or JSON) that includes metering history and audit logs, and test it against your largest tenant.
4. Erase personal data. Under Article 17(1)(a) GDPR, data no longer necessary for its purpose must be erased without undue delay. Cover backups, logs and the analytics warehouse, and pass erasure to each recipient under Article 19 unless that is impossible or disproportionate.
5. Record retention exceptions. Article 17(3)(b) and (e) allow retention for legal obligations and legal claims, which usually covers invoices. Document each exception and its end date.
6. Shut down and prove it. Revoke keys, delete infrastructure and keep a deletion record, because Article 5(2) makes you responsible for demonstrating compliance.

Whether a retired product's data can move to a successor is a separate build or buy decision.

Which compliance evidence does each stage produce?

Each stage of the SaaS development life cycle produces its own compliance evidence, and SOC 2 Type II only accepts that evidence if the controls behind it ran continuously through the audit's observation period.

SOC 2 Type II tests controls against the AICPA Trust Services Criteria: Security, which every audit includes, plus Availability, Processing Integrity, Confidentiality and Privacy where in scope.

ISO/IEC 27001 certifies an information security management system and lists development controls in Annex A, including a secure development life cycle (A.8.25). NIST SP 800-218, the Secure Software Development Framework (SSDF), groups practices into prepare, protect, produce and respond, which gives you a shared vocabulary for naming your controls.

The evidence each stage should generate:

The usual failure is adding controls shortly before the audit. A review rule switched on in month four of a six-month window leaves four months with no samples, and the auditor will qualify the report or extend the window. An early sign is an evidence request answered with screenshots instead of exports from the pipeline or identity provider.

GDPR works differently, because it has no observation period. For the Article 25 duties described in the planning section, the evidence is design records and configuration: default settings, retention config, and erasure job logs showing Article 17 requests propagated to backups and recipients (Article 19 covers notifying recipients). Add an incident runbook mapped to Article 33, and have counsel confirm its notification steps.

We recommend turning on branch protection, ticket-linked changes and pipeline approvals with the first MVP commit. Every later audit window then starts with a full set of samples.

FAQ: SaaS development life cycle

Plan your SaaS release path with Netguru

Planning your SaaS release path starts with two decisions that are expensive to reverse: the multi-tenant architecture and the CI/CD pipeline that ships changes to every tenant. In our view, both cost less to settle before the first paying customer than after the tenth.

If you have a scope or a rough roadmap, send it to us and we will size the stages, gates and team with you.