Search for "SaaS product development lifecycle" and you'll find a hundred neat diagrams with five or six boxes. Idea, design, build, test, launch, maintain. Clean. Easy to remember.
Here is the thing nobody says out loud: there is no official SaaS lifecycle. No standards body publishes one. The cloud vendors don't agree with each other. And the five-box version quietly skips the parts that make SaaS different from shipping software once.
So in this post I'll do something a bit more honest. I'll build a 12-stage lifecycle out of real sources, tell you which source each stage leans on, and point out where the sources disagree. Treat it as a synthesis, not a standard. That's what it is.
Why SaaS is not "normal software plus hosting"
Start with how AWS describes it. In the design principles of its SaaS Lens, AWS writes that "SaaS is a business strategy—not a technical implementation", and that the mindset "centers around the creation of a service experience for customers that focuses on zero downtime, regular updates, and closer connection with customers."
Read that again. Zero downtime. Regular updates. Those are lifecycle requirements, not nice-to-haves. A SaaS product never reaches a "done and shipped" state. It stays alive, with paying customers inside it, while you keep changing it.
The same AWS page also says "There's no one-size-fits-all SaaS architecture", which is a polite way of saying that nobody can hand you a universal lifecycle either.
Microsoft takes a different angle. Instead of stages of building the product, its Azure Architecture Center describes stages in a tenant's life. The page opens with "When you design a multitenant architecture, you must account for each stage in a tenant's life cycle." The headings it lists are: trial tenants, onboard new tenants, update tenants' infrastructure, scale tenants' infrastructure, move tenants between infrastructure, merge and split tenants, offboard tenants, and deactivate and reactivate tenants.
So AWS gives you principles, Microsoft gives you a customer's journey, and NIST (more on that in a moment) gives you security practices. Scrum gives you a delivery rhythm, and the Lean Startup gives you a learning loop. Five sources, five different ways of slicing the same thing.
The lifecycle below borrows from all of them.
Stage 1: Discovery and validation
Before you build anything, find out if anyone wants it. This isn't a one-time step either. The Lean Startup describes the work of a startup as turning ideas into products, measuring how customers respond, and then learning whether to pivot or persevere, all geared to speed up that feedback loop.
My take: treat discovery as a habit, not a phase. If your only customer conversations happen before you write code, you're guessing for the rest of the product's life.
Stage 2: Scope and requirements
This is where most teams write down features and forget everything else. For SaaS, write down the boring operational requirements too.
Microsoft's onboarding guidance gives a useful list of questions to answer early: will onboarding be self-service, automated or manual? Do any customers need their data in a particular region? Do any need to meet standards like HIPAA or PCI DSS? What are your recovery time and recovery point goals? How will billing work?
Security belongs here as well. NIST's Secure Software Development Framework includes practices for documenting security requirements before you build. Put them in the same document as the features.
Stage 3: Architecture and tenancy
This is the stage that's hardest to undo. The big question is how your customers' data and compute are separated: everything shared, everything dedicated, or a mix.
AWS says to "Isolate all tenant resources", because the success of a SaaS system "relies heavily on a security model that ensures that tenant resources are always protected from any cross-tenant access." Microsoft warns about the cost of the fully dedicated route: if one tenant needs a certain infrastructure cost, 100 tenants probably need 100 times that.
I wrote a whole separate post on the shared database, schema and database-per-tenant choice, so I won't repeat it here. The short version is: decide on purpose, and keep an exit open, because your biggest customer will eventually want something different from your smallest one.
Stage 4: Prototype and MVP
Eric Ries defined the minimum viable product in 2009 as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."
Notice what that definition is about. It's about learning, not about shipping less. In the same post, Ries wrote that "MVP, despite the name, is not about creating minimal products." Agile Alliance's glossary names the common mistake: teams stress the "minimum" part and forget the "viable" part.
For SaaS, "viable" has a hidden meaning. A paying customer expects login, a way to pay, and a way not to lose their data. If your MVP has none of those, it's a demo.
Stage 5: Testing
The Scrum Guide gives you the quality bar: when a backlog item meets the Definition of Done, an increment is born. That's the general rule.
SaaS adds its own tests. AWS lists tenant onboarding tests, so that, in its words, "they have a positive experience and that your onboarding flow is resilient, scalable, and efficient." It also lists workflow tests that concentrate load from multiple tenants to find bottlenecks.
Don't skip the cross-tenant test. Create two tenants, give both data, and check that tenant A can never see tenant B's. It's one of the cheapest and most valuable tests a SaaS can have.
Stage 6: Security and compliance, all the way through
NIST's page on the framework says it plainly: "Few software development life cycle (SDLC) models explicitly address software security in detail." So the SSDF is meant to be added to whatever process you already have. Its four practice groups are Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities. The current version is SP 800-218 Version 1.1. You can read it on the NIST SSDF project page.
For web apps, OWASP's Top 10 for 2025 lists broken access control as number one. For a multi-tenant product, that's the bug where one customer reaches another's data, so it matters more here than almost anywhere.
One caution. None of the sources I looked at spells out what SOC 2, HIPAA or GDPR require from a SaaS architecture. Microsoft mentions HIPAA and PCI DSS only as examples of standards a tenant might need. Get the real requirements from the real standards, or from a professional, before you promise anything to a customer.
Stage 7: Infrastructure, CI/CD and safe deployment
SaaS gets updated constantly, so deployment is part of the product. The Twelve-Factor App, written by Adam Wiggins and last updated in 2017, calls itself "a methodology for building software-as-a-service apps." It's old, but its core ideas are still everywhere: keep development and production close, and strictly separate build and run stages.
Microsoft's updates guidance names three common approaches for rolling out changes: deployment stamps, feature flags, and deployment rings. It also reminds you that in a multi-tenant system, different tenants might receive updates at different times. That one sentence changes how you think about versions and database migrations.
Stage 8: Launch
Here's a surprise from the sources: nobody defines "launch" as a formal stage. In Scrum, releasing is separate from sprint boundaries. In Google's SRE book, launch pace is tied to reliability: as long as there's error budget left, new releases can go out.
That's a good rule for a young SaaS. Instead of launching on a date, decide how reliable the product must be, and treat launch as the point where you can meet that bar.
Stage 9: Onboarding, billing and metering
This is the stage that most "lifecycle" posts miss, and the one that separates SaaS from everything else.
AWS says to "Onboard tenants through a single, automated, repeatable process". If creating a customer needs a developer, you can't grow past a handful of customers.
Billing has a trap in it too. Stripe's subscription docs say that a subscription integration needs a webhook destination, "because most subscription activity happens asynchronously." In practice, that means your app shouldn't grant access just because a user came back from a checkout page. Stripe's guidance is to provision access when you receive the invoice-paid event and the subscription status is active, and to verify that incoming events really come from Stripe. A failed payment, a cancelled subscription and a trial ending all arrive the same way, as events your system must handle.
And AWS adds one more principle that's easy to ignore: "Measure the cost impact of individual tenants". If you can't see which customers cost you money, you can't price your product properly.
Stage 10: Operate
After launch, running the product is the job. Google's SRE book makes a point that I find freeing: "100% is the wrong reliability target for basically everything." Pick a target, measure it, and use the gap between the target and perfect as an error budget.
AWS adds the SaaS-specific part. Your operations team needs dashboards that show the activity and load of individual tenants, not just the system as a whole. When a customer complains, "the CPU is fine" isn't an answer.
Stage 11: Iterate and scale
Two things go wrong at this stage. The first is the noisy neighbor. Microsoft puts it this way: be aware of problems where "a sudden increase in load from one subset of tenants degrades performance for others." Its answers are to scale an individual tenant's infrastructure, move tenants between deployments, or provision enough capacity up front.
The second is custom work. AWS recommends supporting one-off requirements as configuration options that are available to any customer, not as code that only one customer gets. Once you start forking your product per customer, you're running a services business with a SaaS logo.
Stage 12: Offboarding and deletion
Almost no one plans for this, and it's an explicit stage in Microsoft's tenant life cycle. Its offboarding section asks you to determine how long to keep customer data, and to identify any legal requirements that mandate destruction after a set period. It also separates deactivation from offboarding: deactivation is meant to be a temporary state.
Decide how export and deletion work before your first customer leaves. It's much easier to build early than to bolt on while a customer is waiting.
A word on roadmaps
Teams argue about this, and the sources do too. Atlassian describes a product roadmap as "a shared source of truth that outlines the vision, direction, priorities, and progress of a product over time." Marty Cagan of SVPG takes a harder line: typical roadmaps "do just what the General warned against – they tell the team what to do." His alternative is a product vision plus prioritized outcomes, because, as he puts it, "It is all about outcome rather than output."
My view is that both are useful if you know what each one is for. A roadmap is good for telling people where you're heading. It's bad when it becomes a list of promised features with dates. Pair it with outcomes, like "reduce the time it takes a new customer to go live," and you get the benefits of both.
How to tell if your lifecycle is working
If you want one set of numbers, use the delivery metrics from DORA. Its guide, last updated January 5, 2026, says DORA has identified five software delivery performance metrics. They are:
- Change lead time: the time it takes for a change to go from committed to version control to deployed in production.
- Deployment frequency: the number of deployments over a given period, or the time between deployments.
- Failed deployment recovery time: the time it takes to recover from a deployment that fails and requires immediate intervention.
- Change fail rate: the ratio of deployments that require immediate intervention following a deployment.
- Deployment rework rate: the ratio of deployments that are unplanned but happen as a result of an incident in production. DORA's key insight is that "speed and stability are not tradeoffs." Many older blog posts still list four metrics and "mean time to recovery". Those lists are out of date.
What I couldn't find
I looked for a reliable, named, dated benchmark for how long each lifecycle stage takes, or what a SaaS MVP costs. I didn't find one. The ranges that rank in search results come mostly from agencies that sell development, so treat any number you see as a sales claim unless it shows its method.
That's worth saying because this topic is full of confident numbers. If a post tells you "stage three takes six weeks", ask where it came from.
The short version
If you take one thing away: the lifecycle of a SaaS product doesn't end at launch, it changes shape. Before launch you're building a product. After launch you're running a service, with customers who join, change, grow, pause and leave. The stages that matter most are the ones the five-box diagrams skip: tenancy, onboarding, billing, operations and offboarding.
A quick disclosure: I work at Entalogics, where we build SaaS products for clients, so I have a bias toward taking these stages seriously early. You can see what our SaaS development service covers. Everything above comes from the public sources named in the text, and you can check each one.
Top comments (0)