METHODOLOGY

SDLC

Software Development Lifecycle

The end-to-end set of stages a software project moves through: discovery, design, build, test, deploy, operate, retire.

Last reviewed: byKevin Riedl wiki ↗

Software Development Lifecycle is the umbrella term for the stages software goes through from idea to retirement. Different methodologies (agile, waterfall, devops, continuous delivery) define different stage boundaries and different ways of moving between them. The stages themselves are roughly invariant: discovery, design, build, test, deploy, operate, retire.

Useful as a vocabulary, not as a process. Teams that try to enforce a strict SDLC end up with documentation overhead that does not survive the second sprint. Teams that ignore the SDLC entirely end up rediscovering each phase the painful way (“we shipped without a deploy plan”, “we did not think about how to retire this”).

Worked example of the stage everyone skips: a startup builds three internal services over two years, ships them, and moves on. Nobody owns “operate” and nobody planned “retire”. Eighteen months later two of the three services are still running, nobody remembers why, the one engineer who understood them has left, and disabling either might break something or might not. That is the unbilled cost of skipping the back half of the lifecycle. The fix is cheap if done up front (name an owner, write a deploy and a teardown plan) and expensive if discovered later.

The methodology you pick mostly decides how rigid the boundaries between stages are. A waterfall SDLC runs them strictly in sequence with sign-offs at each gate; an agile SDLC interleaves design, build, and test continuously and revisits earlier stages as it learns. The stages are the same set either way, which is the useful insight: arguing “agile versus waterfall” is really arguing about how permeable the boundaries should be, and the right answer depends on how much your requirements can still change.

The honest trade-off and common mistake: founders hear “SDLC” and either over-formalise it into a gated, sign-off-heavy process that kills speed, or dismiss it as enterprise theatre and skip the unglamorous stages. The right posture is to treat it as a checklist of things that must happen somewhere, not a sequence to march through. Wavect’s preferred shape: a paid discovery-phase up front, design and build interleaved in short cycles, automated TDD and CI/CD from day one, operate with clear ownership, retire with documented migration paths.

// FAQ

FAQs

No, and teams that try usually drown in documentation overhead. Treat the SDLC as a vocabulary: every project needs discovery, design, build, test, deploy, operate, and retire to happen somewhere. The methodology decides how, not whether.
Retire and operate, in that order. Teams build, ship, and move on, leaving the operational story vague and the retirement plan nonexistent. The bill arrives later, in the form of unowned services no engineer wants to touch.