Software Is a Living Product

A launch is an important milestone, but it is not the end of a useful software product. Users, operating environments, dependencies, security risks, regulations, and business priorities can change. The practical question is therefore not whether software is ever finished in an absolute sense. It is which lifecycle responsibilities the product still has, who owns them, and what evidence justifies the next investment.

The current ISO/IEC/IEEE 12207:2026 software lifecycle standard covers conception, development, operations, support, maintenance, and retirement. It also says lifecycle processes may run concurrently, iteratively, recursively, and incrementally. That is a stronger model than a single sequence of phases that every feature must follow unchanged.

This article turns that lifecycle into a practical product checklist. It is guidance, not a claim that one methodology fits every team.

The building analogy helps, but only up to a point

Software and buildings both benefit from clear intent, constraints, design, verification, integration, operation, and maintenance. The analogy is useful when it reminds a team to make decisions explicit. It becomes misleading when it implies that software requirements can always be completed before implementation or that every change should pass through one rigid sequence.

A product can revisit discovery after user research, change its architecture after load testing, or revise a release after operational data exposes a weak assumption. The lifecycle is better understood as a set of responsibilities with feedback loops than as a conveyor belt.

For each meaningful change, decide which evidence is needed before committing more money. A low-risk copy change may need little ceremony. A payment, identity, health, or safety feature may justify formal requirements, threat modeling, independent review, and controlled rollout.

Seven lifecycle responsibilities to make visible

1. Set an outcome and constraints

Planning should identify the user problem, desired outcome, decision owner, material constraints, and the evidence that would support continuing, changing direction, or stopping. It should also expose assumptions about budget, deadlines, data, integrations, compliance, and operational ownership.

Agile delivery is not the absence of planning. The principles behind the Agile Manifesto combine frequent delivery and responsiveness to changing requirements with sustainable development, technical excellence, and regular reflection. A plan can change while its purpose remains explicit.

2. Refine requirements in proportion to risk

Requirements translate an outcome into behavior, constraints, and acceptance evidence. Teams do not need to predict every future detail, but they should resolve the decisions that are expensive or dangerous to defer. Examples include authorization boundaries, data retention, availability targets, migration rules, and what happens when an external service fails.

Keep unresolved assumptions visible. A prototype can test whether users understand a workflow. A technical spike can test an integration. A small release can test demand. Each experiment should have an owner and a decision it is meant to inform.

3. Design the experience and the system

Experience design covers how people discover, understand, and recover from a workflow. Software design covers responsibilities between components, data boundaries, interfaces, failure behavior, and operational constraints. Both should be detailed enough to make important tradeoffs reviewable before they are buried in implementation.

Architecture is not a synonym for adding services. A modular monolith may be a better fit than distributed services for one product, while another product may need stronger isolation or independent scaling. Choose the simplest structure that satisfies current constraints and leaves credible paths for known change. Record consequential decisions and the evidence behind them.

4. Deliver in reviewable increments

Implementation should produce small enough increments for stakeholders and engineers to inspect. The official 2020 Scrum Guide, for teams that choose Scrum, describes an ordered Product Backlog, a Sprint Goal, a Sprint Backlog, a Definition of Done, and recurring inspection and adaptation. It does not prescribe a contract or pricing model, and it is not the only valid delivery framework.

Useful reporting focuses on decisions and evidence: what outcome moved, what changed, what remains uncertain, which risks increased, and what the team recommends next. Activity counts alone do not establish product value.

For more on commercial structure and uncertainty, see our guide to evaluating software delivery providers.

5. Verify behavior, security, and integration

Testing should be selected from the product's risks. Unit tests can protect local behavior, while integration, contract, end-to-end, performance, accessibility, security, recovery, and migration tests answer different questions. No finite test suite proves that a non-trivial system is defect-free.

NIST's final Secure Software Development Framework 1.1 recommends integrating secure development practices into the chosen lifecycle. Its practices include preparing the organization, protecting software, producing well-secured releases, and responding to vulnerabilities. Security therefore needs design, implementation, verification, release, and response work rather than a single test near launch.

Integrations also need failure-path evidence. Test authentication expiry, rate limits, malformed responses, partial outages, retries, duplicate events, and recovery where those conditions matter. For smart-contract systems, include relevant testnets and carefully controlled production verification, because a test environment cannot reproduce every mainnet dependency or economic condition.

6. Operate and observe the product

A release needs ownership after deployment. Define service indicators, alerts, support routes, incident roles, rollback or mitigation procedures, backup and recovery expectations, and how user feedback reaches the backlog. Observability should answer product and reliability questions without collecting more personal or sensitive data than the product needs.

Operational evidence can contradict design assumptions. Treat incidents, support requests, performance traces, and adoption data as inputs to planning rather than as separate concerns delegated indefinitely to another team.

7. Maintain, evolve, or retire deliberately

Maintenance may include correcting defects, updating dependencies, responding to vulnerabilities, adapting to platform changes, improving operability, and changing behavior as user needs evolve. Not every product needs continuous feature development, but an operated product still needs an explicit decision about ownership and acceptable risk.

A maintenance agreement should make scope concrete: supported environments, response expectations, security update handling, dependency ownership, monitoring, backups, data export, and exit assistance. If the product no longer justifies operation, retirement is also lifecycle work. Plan notification, migration, data retention or deletion, access removal, and decommissioning.

A practical governance checklist

• Outcome: Is the user or business result explicit, with a decision owner?
• Evidence: What would justify proceeding, changing direction, or stopping?
• Risk: Which failure modes deserve stronger requirements, review, or testing?
• Quality: Is the release threshold explicit and observable?
• Operations: Who owns deployment, incidents, support, and recovery?
• Maintenance: Who owns dependencies, vulnerabilities, platform changes, and technical debt?
• Exit: Can users and data move safely if the product or provider changes?

See also: maintaining a living software product may require ongoing technical leadership. If that responsibility does not justify a full-time executive yet, see our Fractional CTO Austria service.