Stages of Software Development: A Practical 2026 Guide

Software development follows six connected stages: discovery, specification, build, test, deploy, and maintenance. They must operate as a continuous loop rather than a one-way hand-off, because poor scope control has contributed to only about 13% of IT projects succeeding against time, budget, and specification, while fewer than 1% of development projects met all three criteria in a cited British Computer Society survey. (UK Parliament)

You've got a promising product idea, a customer who wants it urgently, and a developer ready to open a repository. Before the first user story is written, someone has already chosen a framework, created a hosting account, and started discussing whether the interface should use tabs or a sidebar.

That energy is useful, but it can also hide a dangerous assumption: that coding is the project. In practice, the code is one part of a delivery system that also includes problem discovery, decisions about scope, testing, release, support, and the operational costs that begin on launch day.

The most useful version of the stages of software development isn't a rigid checklist. It's a feedback loop. Evidence from production changes priorities, support questions expose gaps in the specification, security findings reshape the build, and user behaviour informs the next discovery cycle.

Table of Contents

• Why Most Projects Start With a Rush to Code
  • Six stages, one working system
• Discovery and Specification as Your Foundation
  • Turn conversations into constraints
  • The artefacts that protect the build
• Building and Testing Inside a Secure Pipeline
  • What belongs in the pipeline
  • AI needs a tougher definition of “works”
• Waterfall Versus the Modern Delivery Loop
  • The trade-off between certainty and speed
• How UK Studios Apply the Stages in Practice
  • Artefacts should move with the product
• Why Maintenance Costs Often Surprise Founders
  • What live operation must measure
  • Refactor, rebuild, or retire
• Putting the Staged Model to Work for Your Project

Why Most Projects Start With a Rush to Code

A founder wants something demoable by Friday. The product lead wants screens to react to. The developer already has a preferred stack in mind. So the team starts where progress is easiest to display, in design files, in a new repository, in early integrations.

I see this a lot on SaaS and AI work. The pressure is understandable, but the first visible artefacts often harden the weakest assumptions. Once a team has built signup, wired billing, or connected a model to live data, it becomes harder to ask basic questions about approvals, data boundaries, support ownership, or what result the product actually needs to produce.

That is how cost enters the project early. A rushed build can still look efficient in week one while storing up rework for month three. An onboarding flow may be polished before anyone decides who can approve an account. An external API may be integrated before its retention terms are checked. An AI feature may be trained around content the business later realises it cannot expose. None of those mistakes stay in the build stage. They return through testing, deployment, support, and operations.

The history matters here because it explains why staged delivery exists in the first place. In the UK software industry, early custom work was often built for specific clients, then later gave way to packaged and shrink-wrapped products that had to define requirements more clearly before release. That shift pushed teams towards staged delivery because coding first was too risky once products had broader users, repeatable support needs, and commercial constraints. University of Warwick's software history

Six stages, one working system

A practical model uses six connected stages:

• Discovery: Understand the user problem, business outcome, stakeholders, risks, and constraints.
• Specification: Convert that understanding into scope, acceptance criteria, priorities, and measurable behaviour.
• Build: Create the architecture, interfaces, integrations, and versioned code.
• Test: Verify functionality, security, accessibility, performance, data handling, and failure behaviour.
• Deploy: Promote an approved build with ownership, monitoring, documentation, and rollback arrangements.
• Maintenance: Operate, support, patch, observe, improve, refactor, and eventually retire the product.

Each stage produces evidence for the next. Production then sends evidence back the other way. A support ticket can expose a bad discovery assumption. A failed integration test can force a specification change. A growing infrastructure bill can turn a technically successful feature into a poor business decision.

Practical rule: Move quickly through decisions, not blindly through stages.

Teams that treat code as the start and finish of delivery usually pay for that decision later, in rework, support load, and operating cost. Teams that treat the stages as a loop get more chances to correct course before those costs become fixed.

Discovery and Specification as Your Foundation

A project can look healthy at this stage and still be storing up cost. I see it when a founder wants a dashboard, an AI workflow, or a customer portal, but the pressure sits elsewhere: unclear approval rules, weak account controls, a support team that cannot trace what happened, or a billing edge case nobody has named. Discovery needs to expose those operating conditions early, because they shape build effort and they keep shaping cost after launch.

For SaaS products, that usually means pinning down subscription changes, account ownership, audit trails, accessibility, data protection, and support escalation. For AI features, the questions get sharper. What can the system decide on its own, when does a person approve the result, how is uncertainty handled, and what is recorded for review later? Those are product questions and operational questions at the same time.

The UK Government Software Security Code of Practice places requirements gathering and analysis before design and implementation, and it recommends secure-by-design practice throughout the lifecycle rather than trying to bolt security on during final testing. That ordering matters. If a team leaves risk, access control, or failure handling until the end, the expensive version of the conversation starts.

Turn conversations into constraints

Useful discovery work gives the team boundaries they can build inside:

• User need: Who needs what, and in which context?
• Business outcome: What decision will show the product is useful?
• Operational boundary: Which systems, suppliers, teams, and support processes are involved?
• Risk boundary: What must be protected, logged, reviewed, or blocked?
• Delivery boundary: What belongs in the first release, and what is out of scope?

Specification turns that into testable behaviour. “Users can upload a document” is only a prompt. A usable specification defines file types, permissions, error states, failed processing behaviour, and the checks that prove the feature works. Design then follows those choices. Teams that want a practical reference for interaction decisions can use a focused UI and UX design guide alongside the product requirements.

The artefacts that protect the build

The documents that earn their keep are usually short, current, and tied to decisions:

1. Problem statement: The user problem and business reason for solving it.
2. Scope map: Included capabilities, exclusions, dependencies, and assumptions.
3. Acceptance criteria: Observable conditions that define a completed feature.
4. Risk register: Security, legal, technical, operational, and supplier risks.
5. Release outline: The smallest useful release and the evidence required to approve it.

Get these right and discovery stops being a gate before coding. It becomes the first pass through a delivery loop, one that reduces rework now and avoids avoidable support, compliance, and operating cost later.

Building and Testing Inside a Secure Pipeline

Build and test shouldn't be treated as separate blocks where developers write everything first and testers search for problems at the end. Implementation creates versioned code, while testing continuously checks whether that code behaves as intended and remains safe when combined with other components.

A sensible pipeline starts with fast checks at commit time. Linting catches inconsistent or risky patterns. Unit tests validate isolated functions. Dependency checks identify software-component concerns. Static analysis examines code without running the application, while integration tests reveal problems that only appear when services, databases, queues, or external APIs interact.

What belongs in the pipeline

The exact controls depend on the product, but the decision should be explicit:

• Code quality checks: Run formatting, linting, type checks, and static analysis before a change is merged.
• Unit coverage: Test business rules and important edge cases in isolation.
• Integration checks: Exercise real boundaries between the application, data stores, identity services, and third-party systems.
• Security checks: Include dependency or software-composition analysis, security-focused static analysis, and dynamic testing where appropriate.
• Acceptance tests: Verify the criteria agreed during specification, not merely whether the page loads.
• Release evidence: Record the approved build, outstanding defects, migration steps, monitoring, and rollback procedure.

NCSC guidance recommends testing both software components and the final integrated package, documenting defects and vulnerabilities, and establishing code-coverage expectations before code is committed. It also advises integrating security testing into the build pipeline at the same speed as the broader development lifecycle. (NCSC implementation guidance for secure design and development)

AI needs a tougher definition of “works”

An AI integration can pass a conventional happy-path test and still fail in a way that damages trust. Test representative inputs, ambiguous requests, missing data, prompt manipulation, unsafe outputs, escalation behaviour, and service outages. For an agent that can take actions, separate generation from approval and constrain the operations it can perform.

The practical objective isn't to eliminate every defect. It's to make failures visible early, stop known regressions from reaching production, and give the team repeatable evidence before release. Delaying quality and security work creates a queue of uncertainty that becomes harder to resolve as more code depends on it.

A web application architecture reference can help teams make these boundaries explicit before implementation expands across services and integrations.

Waterfall Versus the Modern Delivery Loop

A founder approves a build, the team ships on time, and everyone relaxes for a week. Then the actual work starts. Users behave differently from the spec, support tickets expose edge cases, cloud bills appear, a supplier changes an API, and the product team has to decide what gets fixed now and what becomes accepted operational cost.

That is why the choice is rarely “waterfall or agile” in the simplistic sense. Waterfall works in some settings. If requirements are stable, approvals are formal, dependencies are known, and late design changes carry legal, safety, or procurement risk, a staged model can be the sensible choice. Regulated organisations often need clear sign-off points because someone must own each decision.

Problems start when a staged model is treated as a one-way conveyor belt. Requirements get frozen too early, testing is pushed toward the end, and maintenance inherits design decisions it did not help shape. New evidence then arrives as a problem to contain rather than an input to use.

Modern delivery keeps the stages and changes the relationship between them. Discovery informs specification. Specification guides the build. Testing produces evidence. Release exposes real behaviour under real usage. Operations and maintenance then feed that learning back into discovery, where the next round of priorities is set. The sequence still exists, but in practice it behaves as a loop.

That loop reflects how software behaves in service, especially in the UK public and regulated context, where digital teams have long had to balance governance with iteration. The lesson is practical. Control matters, but delayed feedback is expensive.

The trade-off between certainty and speed

In practice, the strongest teams combine approaches. They keep formal decision points where risk is high, then use short delivery cycles inside those boundaries. I have seen this work well on SaaS products with AI features, where governance cannot disappear, but neither can feedback from production.

An MVP should be narrow, not careless. A first release can still define authentication, data ownership, backups, monitoring, accessibility expectations, and rollback. Minimum viable product describes scope, not an excuse to lower the standard of care.

Release is also where recurring business cost becomes visible. Infrastructure, support, patching, supplier management, and customer communication continue long after launch. Maintenance is not the last box on a checklist. It is the stage that reveals whether earlier decisions were efficient, fragile, or only deferred.

How UK Studios Apply the Stages in Practice

Consider a London studio delivering a SaaS platform for a regulated client. The client wants an AI assistant that classifies incoming requests, drafts responses, and routes uncertain cases to a human reviewer. The attractive part is the interface. The difficult part is everything that defines acceptable behaviour around it.

Discovery identifies the users, the current workflow, the information involved, the approval points, and the consequences of a wrong classification. It also surfaces subscription requirements, reporting needs, supplier dependencies, and the client's responsibilities for data protection and operational support.

Specification turns that knowledge into artefacts the delivery team can challenge. Acceptance criteria might define which requests the assistant can handle, when it must abstain, which evidence it must retain, and who approves an outgoing response. The team records reliability expectations as testable behaviour rather than promising that the model will be “accurate”.

Artefacts should move with the product

The build produces the web application, identity and billing integrations, administration tools, and AI connection. It also produces configuration, logs, documentation, and deployment definitions. Those supporting materials matter because another person must operate the product when the original developer isn't available.

Testing then goes beyond clicking through the main journey:

• Functional validation: Does the application implement the agreed workflows?
• Security review: Can users access only the information and actions assigned to them?
• AI evaluation: Does the feature handle representative requests, ambiguity, unsafe instructions, and missing context?
• Human oversight: Can a reviewer understand, correct, and escalate the system's output?
• Operational testing: Do alerts, backups, patching procedures, and rollback steps work as intended?

Deploying an approved build means more than pressing a release button. The team needs a named operational owner, a rollback plan, monitoring that surfaces meaningful failures, and a clear support route. If a model provider changes behaviour or pricing, someone must know who reviews the impact.

Maintenance watches cost, reliability, response quality, drift, user complaints, and operational workload. Those signals feed the next prioritisation cycle. A rise in manual review may justify better rules, revised prompts, a narrower use case, or retirement of the AI feature. The correct response isn't always more model complexity.

The UK evidence on AI adoption is uneven because surveys use different populations, timings, and definitions. ONS analysis reports that UK businesses with at least ten employees using at least one AI technology rose from about 12% in late 2023 to roughly 35% by June 2026, while DSIT research reports 16% usage and 80% of businesses neither using AI nor planning adoption during its cited research period. (ONS analysis of AI in UK businesses) That variation is a useful warning: AI discovery must establish the actual problem and evidence base before a team treats adoption as a product strategy.

Why Maintenance Costs Often Surprise Founders

Founders often budget for design and development, then describe maintenance as a small allowance after launch. That framing misses the commercial reality. Once customers depend on a product, every technical decision creates ongoing work involving infrastructure, security updates, support, monitoring, documentation, suppliers, and data.

The UK Government's review of digital government reports that maintaining legacy systems can cost three to four times more than modern alternatives. (State of digital government review) The point isn't that every new product will become a legacy system. It's that postponing ownership decisions can turn a cheap release into an expensive operating environment.

What live operation must measure

A product team needs operational evidence that connects engineering behaviour to business impact:

• Reliability: Which failures affect customers, how often do they occur, and how quickly are they detected?
• Support load: Which issues consume human time, and which requests indicate a confusing workflow?
• Security posture: Are patches, vulnerabilities, access reviews, and incident procedures actively owned?
• Performance and cost: Which features or suppliers consume disproportionate resources?
• Accessibility: Do real users encounter barriers that scripted tests missed?
• AI behaviour: Are output quality, refusal behaviour, drift, cost, and human escalations changing?

These measurements should influence prioritisation, not sit in a dashboard nobody reviews. A recurring support problem may deserve product work. A brittle integration may need replacement before it fails during a critical customer process. A feature with low adoption but high maintenance may be a candidate for retirement.

Refactor, rebuild, or retire

Refactoring makes sense when the product remains valuable and the underlying design can be improved without changing its core purpose. Rebuilding becomes more credible when the architecture blocks essential capabilities, documentation has disappeared, or changes repeatedly create regressions. Retirement is responsible when the product no longer justifies its operational cost or a safer replacement exists.

Budget for these decisions from the beginning. Include infrastructure ownership, monitoring, backups, migration planning, patch validation, vendor review, incident response, and support documentation in the product's whole-life plan. “Launch now, sort out operations later” is often just deferred spending with less information and more pressure.

Putting the Staged Model to Work for Your Project

Start with a one-page delivery map. Write the problem, intended users, business outcome, constraints, first release, operational owner, and evidence required for approval. If the team can't agree on those points, more code won't create clarity.

Then give each stage a transition rule:

• Discovery to specification: The problem, users, constraints, and exclusions are understood well enough to define observable outcomes.
• Specification to build: Acceptance criteria, risks, design decisions, dependencies, and ownership are recorded.
• Build to test: The change is versioned, reviewable, and accompanied by the checks needed to verify its behaviour.
• Test to deploy: Functional and security evidence is acceptable, known risks are owned, and rollback is possible.
• Deploy to maintenance: Monitoring, support, documentation, patching, and incident ownership are active.
• Maintenance to discovery: Production evidence identifies the next valuable change, refactor, supplier decision, or retirement candidate.

For an MVP, keep the feature boundary narrow but don't remove the controls that protect customers and the business. For an AI integration, add data-quality review, privacy assessment, security testing, human oversight, harmful-failure evaluation, cost monitoring, and drift checks. Buying an external AI service, integrating a model into an existing product, and building an agent that takes actions are different delivery decisions with different ownership requirements.

The same loop works for a web application, a subscription platform, an interactive simulation, or an internal automation tool. You can use a practical web application development process to organise the work, but the important discipline is broader than a framework or project board. Treat requirements as constraints, testing as continuous evidence, deployment as an operational handover, and maintenance as product management.

A good delivery process doesn't slow a capable team down. It prevents the team from spending speed on the wrong problem, and it gives founders a clearer choice between improving, rebuilding, or retiring what they've shipped.

---

Digital Souls Studios LTD designs and builds web applications, SaaS products, AI automation, and interactive experiences, covering specification, design, engineering, infrastructure, launch, and ongoing support. If your team needs to turn a product idea into a properly staged delivery loop, visit Digital Souls Studios LTD to discuss the project and its operational requirements.