TL;DR — the six stages at a glance
The custom software development process runs through six stages: discovery, design and architecture, development sprints, testing and QA, deployment and launch, and ongoing support. A medium-complexity build takes 5–9 months, and development alone eats 55–65% of the budget. Discovery gives the best return of any phase: skip it and you usually pay for it later, in 30–50% mid-build rework.
Every custom software development project moves through the same six phases, whether the team runs pure agile or a hybrid model. Skip a stage, or rush it, and the downstream costs usually dwarf the time you 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: only its output makes a fixed-price or capped time-and-materials quote worth anything. Without it, any fixed quote is a guess.
Skip discovery and the symptoms are always the same. Requirements shift after the architecture is locked. Integrations surface mid-sprint. Compliance gets retrofitted once the software is already live. Each of these costs more to fix than the discovery phase would have cost in the first place. Our guide to MVP development takes a complementary angle 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. Getting the UX right before development starts is not a cosmetic nicety. It heads off the most expensive rework there is: rebuilding an interface that real users reject. A solid component library speeds things up too, because engineers build against one consistent system instead of reinventing UI screen by 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.
Decisions made here are expensive to reverse. Pick the wrong data-partitioning strategy and you may be paying for a full data migration six months later. This is where senior architects earn their fee: they weigh the real trade-offs instead of reaching for whatever happens to be familiar or fashionable.
Stage 3: Development sprints
Development eats the largest share of the budget, typically 55–65% of total project cost. For medium-complexity projects it runs 12–24 weeks across multiple agile sprints.
Every sprint follows the same rhythm: planning (set sprint goals from the backlog), build (engineers implement the agreed stories), review (demo working software to stakeholders), retrospective (agree what to improve next time). Why two weeks? Short cycles catch misalignment while it is still cheap to fix, long before delivery day turns it into an expensive problem.
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.
If you carry compliance requirements (GDPR data residency, SOC 2 audit trail, HIPAA PHI handling), bake the controls into sprint stories from day one. Bolting them on after delivery costs far more and satisfies no auditor. Our custom software development service page explains 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, not overnight, but steadily. Dependencies fall out of date. Security holes pile up. Performance sags as data volumes climb. What ran fine at 100 users starts to buckle 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.
At this stage iteration stops being maintenance and becomes product development. Analytics, support tickets and sales feedback all feed a prioritised backlog. New features ship faster and cheaper now than during the initial build: the architecture is settled, the team knows the codebase, the CI/CD pipeline already runs. Your choice of partner matters here. You want a team that can handle steady long-term upkeep and quick feature work in the same breath. Read our guide on how to choose a software development company to judge partners on both dimensions.
Agile, waterfall or hybrid: which delivery model?
The six stages describe what gets built; the delivery model decides how the team sequences them. For most custom software in 2026 the pragmatic default is a hybrid: structured discovery and architecture up front, then agile sprints for the build. Pure waterfall turns brittle the moment requirements start to move. Pure agile, with no architecture gate, quietly runs up technical debt. The table below weighs the three approaches on the criteria that actually matter when you pick a delivery partner.
| Model | Best fit | Handles changing scope | Upfront certainty |
|---|---|---|---|
| Waterfall | Fixed, fully specified scope; hard regulatory sign-off gates | Poorly — changes are expensive | High cost/date certainty, low outcome certainty |
| Agile (Scrum/Kanban) | Product-led builds where requirements evolve with user feedback | Well — reprioritise every sprint | Lower date certainty without an architecture gate |
| Hybrid (recommended) | Most mid-market and enterprise custom software | Well, within an agreed architecture | Balanced — scoped discovery plus agile flexibility |
According to the Project Management Institute (Pulse of the Profession, 2024), organisations using hybrid delivery report higher project success rates than those on a single rigid methodology. In practice, the model matters less than the discipline behind it: a defined architecture, working software every sprint and a real QA gate before launch. For a deeper look at how we structure compliant hybrid delivery, see our custom software development service.
Who is on a custom software development team?
The process only works if the right people are in the right seats. A team that is missing a role — or where roles overlap badly — produces exactly the kind of delays, rework and scope drift the six-stage process is designed to prevent. Here is who you typically need for a medium-complexity custom software project.
| Role | Responsibility | Active in phases |
|---|---|---|
| Product Owner (client side) | Sets business priorities, owns the backlog, approves sprint demos | All phases |
| Project Manager | Timeline, budget, risk register, stakeholder communication, sprint coordination | All phases |
| Business Analyst | Requirements elicitation, user stories, acceptance criteria, gap analysis | Discovery, Design |
| Solution Architect | Technology stack, system design, integration strategy, ADRs | Discovery, Design, Sprints |
| UX/UI Designer | User flows, wireframes, component library, design system | Design, Sprints |
| Backend Developer(s) | API, business logic, database, integrations, security controls | Sprints |
| Frontend Developer(s) | UI implementation, performance, accessibility | Sprints |
| QA Engineer | Test strategy, automation suite, bug reports, regression coverage | Sprints, QA, Launch |
| DevOps Engineer | CI/CD pipeline, cloud infrastructure, monitoring, deployment | Design, Launch, Support |
For a 12-week MVP build, the minimum viable team is typically: PM, one backend developer, one frontend developer and a part-time QA engineer. Architect and DevOps involvement is often shared or split. Enterprise builds require dedicated resources in all seats. Trying to save cost by merging the PM and BA role, or by skipping the architect, is one of the most reliable predictors of scope creep and delayed launches.
How to control scope and budget during the build
The most common reason custom software projects go over budget is not bad engineering — it is uncontrolled scope change. Every feature added mid-sprint without a corresponding trade-off pushes costs up and timelines out. Here are the four mechanisms that keep a project inside its envelope.
1. Lock the architecture, flex the features
The discovery phase produces an architecture that should not change mid-build without a formal change request. Individual features within that architecture can be added, deprioritised or swapped. The architecture cannot. Teams that treat the ADR as negotiable at every planning meeting routinely blow both budgets and timelines.
2. Change request discipline
Any requirement that was not in the agreed scope document should trigger a written change request, with an estimate and a decision: add it now (and adjust budget/timeline), add it to backlog for later, or reject it. Verbal scope additions that skip this process are the number-one cause of "how did we end up here" conversations at project close. Industry data consistently shows that unmanaged change requests add 15–30% to final project costs.
3. Sprint velocity as your early-warning system
Track story points completed per sprint from sprint 1. A team delivering 70% of its committed points sprint after sprint is signalling either estimation problems or technical debt accumulating faster than it is being repaid. Either issue is fixable early and expensive to ignore. A healthy velocity should stabilise by sprint 3 and hold. If it is still declining by sprint 6, ask for a root-cause review.
4. Reserve budget, not contingency theatre
Budget a genuine 15–20% reserve on top of the development estimate. This is not a sign of a padded quote — it is the industry-standard buffer for integration surprises, compliance requirements that surface during build, and genuine scope improvements that emerge from user testing. Projects that start with no reserve invariably raid the QA or launch budget when the first surprise hits, and they always hit.
Common mistakes that derail custom software projects
Most software project failures are predictable. The same patterns appear so consistently that a vendor who has shipped dozens of projects will recognise them in the first discovery conversation. Here are the six most damaging mistakes — and how to avoid them.
Skipping or abbreviating discovery
Covered above, but worth repeating: this is the single most expensive mistake in custom software. A vendor who starts writing code in week one has no foundation for anything they build. Requirements will shift, architecture will be retrofitted and the final product will look nothing like the original scope — at 150% of the original cost.
Choosing on price alone
The lowest quote is almost always the lowest because it omits something: discovery, QA, senior architect time, or support. Build cost models that rely on junior-only teams, offshore outsourcing with no management layer, or fixed prices with no discovery phase all share one property: they move the cost, not eliminate it. The rework bill arrives later, and it is always larger than the savings from the cheaper quote.
No product owner involvement during sprints
A product owner who reviews demos quarterly instead of bi-weekly will find at the end of the project that the team built what was written in the requirements, not what was actually needed. Requirements cannot anticipate everything. Sprint reviews exist precisely to course-correct before it is expensive. Clients who attend every sprint demo consistently report higher satisfaction with the final product.
Retrofitting compliance
GDPR data residency, SOC 2 audit trails, HIPAA PHI handling, PCI-DSS cardholder data controls — all of these must be baked into sprint stories from day one, not added after the audit request arrives. Compliance retrofitted post-launch typically costs 3–5× what it would have cost if designed in from the start, and it often requires partial rebuilds of the data model.
Cutting the QA cycle
When projects run late, QA is the first thing teams propose to shorten. This is backwards: a compressed QA cycle means bugs that testing would have caught instead get caught by real users in production. The cost of a production incident — engineering time, customer trust, potential regulatory exposure — consistently exceeds the cost of the QA time that would have prevented it.
No post-launch maintenance budget
Software without an active maintenance contract degrades within 12 months: security CVEs pile up, dependencies fall out of support, and performance erodes under growing data volumes. Budget 15–20% of build cost per year from day one. It is not optional — it is the difference between a 5-year asset and a 2-year liability.
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.
Who should be on a custom software development team?
A minimum viable team for a medium-complexity project includes: a project manager, solution architect, backend developer(s), frontend developer(s), QA engineer and DevOps engineer. On the client side, a dedicated product owner who attends sprint demos is essential. Large enterprise builds add a business analyst, security engineer and data engineer. Skipping the architect role to save cost is the most reliable predictor of costly architectural pivots mid-build.
How do I prevent scope creep in custom software development?
Scope creep is controlled by four mechanisms: (1) a discovery phase that produces a signed-off requirements document and architecture before development begins; (2) a formal change request process for any post-kick-off additions, each with an estimate and a decision; (3) sprint velocity tracking as an early-warning system for accumulating technical debt; and (4) a 15–20% budget reserve held explicitly for confirmed scope improvements, not undefined contingency. Unmanaged scope changes add 15–30% to final project costs on average.
What are the most common reasons custom software projects fail?
The six most consistent failure patterns are: skipping or abbreviating discovery; selecting a vendor on price alone; insufficient product owner participation during sprints; retrofitting compliance controls after the architecture is locked; compressing or eliminating QA to recover schedule; and launching with no post-launch maintenance budget. All six are avoidable with the right process and the right vendor selection criteria. The common thread is that each mistake saves cost in the short term and creates a much larger cost downstream.
How much does the custom software development process cost in total?
For a medium-complexity platform: discovery $15,000–$25,000; design and architecture $10,000–$20,000; development $60,000–$150,000; QA $10,000–$20,000; deployment $5,000–$10,000. Total build: $100,000–$250,000. Add 15–20% per year for ongoing support. Enterprise builds start at $250,000 and frequently exceed $1M including multi-year maintenance. See our detailed guide to custom software development cost in 2026 for a full breakdown by project type and team model.
Published 21 May 2026; updated 11 September 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.
