TL;DR — the six stages at a glance
Every successful custom software project moves through the same six phases, regardless of whether the team is agile or hybrid. Skipping or rushing any stage creates downstream costs that consistently exceed the time saved. Here is the short version:
- Discovery: Define what to build and why — requirements, scope, data model, architecture decisions. 4–6 weeks.
- Design & architecture: UX wireframes, UI designs, system blueprint. 3–5 weeks.
- Development sprints: Iterative agile build, working software every 2 weeks. 12–24 weeks for medium projects.
- Testing & QA: Automated tests, manual QA, security review, performance profiling. 3–5 weeks (overlapping with sprints).
- Deployment & launch: Staging verification, production release, go-live monitoring. 1–2 weeks.
- Support & iteration: Bug fixes, security patches, feature releases. 15–20% of build cost per year.
Overview: the full SDLC in one table
The table below summarises what each phase produces, how long it typically takes and where it fits in the total project cost for a medium-complexity platform ($100,000–$250,000 build).
| Stage | Key outputs | Typical duration | % of build cost |
|---|---|---|---|
| 1. Discovery | Requirements doc, data model, architecture decision record, project charter | 4–6 weeks | 10–15% |
| 2. Design & architecture | Wireframes, UI system, API contracts, infrastructure diagram | 3–5 weeks | 8–12% |
| 3. Development sprints | Working software increments, sprint demos, release-ready builds | 12–24 weeks | 55–65% |
| 4. Testing & QA | Automated test suite, QA report, security findings, performance baseline | 3–5 weeks | 8–12% |
| 5. Deployment & launch | Production environment, CI/CD pipeline, runbook, go-live checklist | 1–2 weeks | 3–5% |
| 6. Support & iteration | Patch releases, feature increments, monitoring dashboards | Ongoing | 15–20% /yr |
Stage 1: Discovery
Discovery is the most consequential phase in the entire software development lifecycle. It turns a business problem into a buildable technical specification. Without it, development teams build the wrong thing at full speed.
A well-run discovery phase produces four core artefacts:
- Requirements document: user stories, acceptance criteria, out-of-scope decisions and edge-case handling.
- Data model: the entities, relationships and constraints that the system must represent. This is the foundation of every architectural decision that follows.
- Architecture decision record (ADR): technology stack, integration points, hosting strategy, compliance requirements and trade-offs documented with rationale.
- Project charter: scope, milestones, team composition, communication cadence and escalation paths.
Discovery typically runs 4–6 weeks for a medium-complexity project and costs $15,000–$25,000 with a senior nearshore team. It is almost always priced separately from the main build — and rightly so. The output of discovery is what allows a fixed-price or capped-time-and-materials quote to be meaningful. Without it, any fixed quote is a guess.
Teams that skip discovery consistently report the same symptoms: requirements changing after architecture is set, integrations discovered mid-sprint, compliance requirements retrofitted post-launch. Each of these is more expensive to fix than a full discovery phase would have cost. See our guide to MVP development for a complementary perspective on scoping early-stage projects.
Stage 2: Design & architecture
Design and architecture translates the discovery artefacts into the visual and structural blueprint the development team will build against. It runs in two parallel workstreams.
UX and UI design produces user flows, wireframes and high-fidelity mockups. For product-facing software, getting the UX right before development starts is not cosmetic — it prevents the most expensive kind of rework: rebuilding UI that real users reject. A well-designed component library also accelerates development, since engineers build against a consistent system rather than inventing UI from scratch per screen.
System architecture produces the infrastructure diagram, API contracts, data migration plan (if applicable) and the technical runbook. Key decisions made here include: monolith vs microservices, synchronous vs event-driven communication, authentication and authorisation strategy, data residency and encryption requirements, and CI/CD pipeline design.
Architecture decisions made in this phase are expensive to reverse. Choosing the wrong data partitioning strategy, for instance, can require a complete data migration six months later. Senior architects earn their cost in this phase by making informed trade-offs rather than defaulting to the familiar or the fashionable.
Stage 3: Development sprints
Development is where the largest portion of the budget is consumed — typically 55–65% of total project cost. For medium-complexity projects it runs 12–24 weeks across multiple agile sprints.
Each sprint follows the same rhythm: planning (define sprint goals from the backlog), build (engineers implement agreed stories), review (working software demonstrated to stakeholders), retrospective (team improvement action). The two-week sprint cadence serves one critical function: it surfaces misalignments early, when they are cheap to correct, rather than at delivery, when they are not.
Key engineering practices that separate professional delivery from amateur delivery:
- Code review: every pull request reviewed by at least one senior engineer before merge. Prevents accumulation of technical debt.
- Automated testing: unit, integration and end-to-end tests written in parallel with features, not as an afterthought. Minimum 70% code coverage on critical paths.
- Feature flags: new functionality deployed behind flags, allowing incremental rollout and safe rollback without deployment overhead.
- Security-by-construction: input validation, secrets management, OWASP Top 10 mitigations and dependency vulnerability scanning built into the development workflow, not retrofitted in QA.
For teams with compliance requirements (GDPR data residency, SOC 2 audit trail, HIPAA PHI handling), the compliance controls must be baked into sprint stories from the start, not bolted on after delivery. See our custom software development service page for details on how we structure compliant agile delivery.
Stage 4: Testing & QA
Quality assurance runs in parallel with development sprints rather than as a discrete post-build phase. But a dedicated QA cycle at the end of development remains essential before any production release.
The testing pyramid for production-grade software covers four layers:
- Unit tests: fast, isolated tests of individual functions and components. Run on every commit. Should cover 70%+ of business logic.
- Integration tests: verify that components and services interact correctly. Cover critical API contracts and database operations.
- End-to-end tests: simulate real user journeys through a deployed environment. Cover all primary user flows and edge cases documented in discovery.
- Non-functional testing: performance profiling under realistic load, security penetration testing (for regulated environments), accessibility audit (WCAG 2.1 AA minimum for EU/US public-facing software).
A security penetration test is non-negotiable for any software handling personal data (GDPR compliance), financial transactions (PCI-DSS) or healthcare records (HIPAA). For EU-facing software, the GDPR data processing impact assessment (DPIA) is a legal requirement for high-risk processing activities and should be completed before launch, not after a regulator request.
Stage 5: Deployment & launch
Deployment is the shortest phase but the one with the highest public visibility. A botched launch creates a trust problem that takes weeks of operational messaging to recover from, regardless of the technical quality of the software.
Production-grade deployment for a medium-complexity project covers:
- Infrastructure provisioning: cloud environment configured for production load, security groups, backup policies and alerting in place.
- CI/CD pipeline: automated build, test and deployment pipeline so future releases take minutes, not days.
- Staged rollout: production traffic moved from old to new system in increments (5% → 25% → 100%) with automated rollback triggers if error rates spike.
- Go-live monitoring: real-time dashboards for error rate, latency, throughput and infrastructure metrics for the first 72 hours post-launch. On-call engineering coverage during this window is expected.
- Operations runbook: documented procedures for common operational tasks, incident response and escalation paths. Essential for client engineering teams taking over post-handover.
Stage 6: Support & iteration
Software that is not actively maintained degrades. Not dramatically or immediately — but steadily. Dependencies become outdated. Security vulnerabilities accumulate. Performance degrades as data volumes grow. Features that worked at 100 users break at 10,000.
Industry benchmarks consistently place ongoing support and maintenance at 15–20% of the original build cost per year. What that budget covers for a typical medium-complexity platform:
- Security patches and dependency updates: critical and high CVEs patched within agreed SLAs (typically 24–72 hours for critical). Non-negotiable.
- Bug fixes from real user feedback: the first 90 days post-launch typically surface the majority of edge-case bugs that testing missed.
- Infrastructure scaling: capacity adjustments as user base grows, cost optimisation as usage patterns stabilise.
- Feature iterations: user-data-driven feature additions, UX improvements and integrations driven by the product roadmap.
- Monitoring and on-call: 24/7 alerting with defined response SLAs. For revenue-critical software, P1 incidents must be acknowledged within 15 minutes.
For a $150,000 build, budget $22,500–$30,000 per year for support. For a $300,000 build, $45,000–$60,000 per year. Teams that cut the support budget to zero typically face a forced full rewrite within 3–5 years at 150–200% of the original build cost. See our guide to custom software development cost in 2026 for the full maintenance cost model.
Iteration in this phase is not maintenance — it is product development. User analytics, support tickets and sales feedback feed a prioritised backlog. Feature releases at this stage are faster and cheaper than during the initial build, because the architecture is established, the team knows the codebase and the CI/CD pipeline is operational. Choosing the right development partner matters here: you want a team capable of both long-term maintenance and rapid feature delivery. Read our guide on how to choose a software development company to evaluate partners on both dimensions.
FAQ
What are the stages of software development?
The six core stages are: discovery (requirements and architecture), design and architecture (UX and system blueprints), development sprints (iterative agile build), testing and QA (automated and manual verification), deployment and launch (production release), and support and iteration (maintenance and feature evolution). Each stage produces specific artefacts and gates the next phase. Skipping stages creates downstream costs that consistently exceed the time saved.
Why is the discovery phase important?
Discovery converts a business problem into a concrete, buildable technical specification before any development budget is committed. It identifies integration complexity, compliance requirements and architectural constraints that would otherwise surface as expensive mid-build surprises. Projects that invest in a proper 4–6 week discovery phase routinely save 30–50% in mid-build rework. A discovery phase costing $15,000–$25,000 is the highest-ROI investment in any custom software project.
How long does each phase take?
For a medium-complexity project: discovery 4–6 weeks; design and architecture 3–5 weeks; development sprints 12–24 weeks; testing and QA 3–5 weeks (overlapping with sprints); deployment and launch 1–2 weeks. Total end-to-end timeline is typically 5–9 months from kick-off to production launch. Complex enterprise projects run 12–24 months.
Do you use agile or waterfall?
We use a hybrid: structured discovery and architecture phases (light waterfall gates) followed by agile two-week sprints for delivery. This combines architectural rigour with delivery flexibility. Pure waterfall is unsuitable for most custom software because requirements evolve. Pure agile without upfront architecture produces technical debt that compounds over time. The hybrid is the current industry standard for mid-market and enterprise custom software.
What happens after launch?
Software enters the support and iteration phase: security patches, bug fixes, infrastructure scaling and feature releases. Budget 15–20% of the build cost per year for this phase. Post-launch iteration is faster and cheaper than the initial build because the architecture and CI/CD pipeline are already in place. Do not cut this budget — deferred maintenance creates compounding technical debt that forces a full rewrite within 3–5 years.
Published 21 May 2026. Process timelines and cost percentages reflect senior nearshore delivery for mid-complexity custom software projects. Individual project timelines vary based on scope, integration complexity and compliance requirements.
