A custom software project runs through 7 stages between the first discovery conversation and go-live, each with its own deliverables and share of the overall timeline. In 2026, most delays we see on client projects don't actually come from development itself — they come from discovery and acceptance testing, the two stages that get treated as "soft" and rushed. This guide breaks down what each stage delivers, how much of the timeline it typically takes, what you as the client need to do at each point, and how Agile and Waterfall change the shape of that work.
The 7 Stages of Software Development, at a Glance
The table below maps the seven stages from discovery through launch handover, including each stage's deliverables, its typical share of the total timeline, and what the client side needs to contribute. These percentages hold whether the project is a 6-12 week MVP or a 3-6 month enterprise build — only the number of weeks per stage changes.
| Stage | Deliverables | % of Timeline | What the Client Needs to Do |
|---|---|---|---|
| 1. Discovery | Requirements spec, stakeholder interview notes, initial timeline and budget estimate | 10% | Assign an internal point of contact, join 2-3 rounds of interviews, share existing system and process documentation |
| 2. Planning & Architecture | System architecture diagram, tech stack decisions, database schema draft, project timeline | 15% | Confirm architecture direction and tech stack, sign off on milestone dates |
| 3. Design | Wireframes, high-fidelity UI mockups, interactive prototype, design guidelines | 15% | Share brand guidelines or existing UI, return feedback on mockups within 24-48 hours |
| 4. Development | Working feature modules delivered every two weeks, version-controlled source, API documentation | 35% | Review each two-week iteration, stay reachable, flag gaps between what's built and what's expected |
| 5. Testing & QA | Test plan, test cases, bug tracker with fixes logged, performance test report | 15% | Provide de-identified real test data, confirm edge cases and exception scenarios |
| 6. UAT & Acceptance | UAT test log, sign-off documentation, draft user manual | 5% | Have real end users run UAT, compile a punch list, complete formal sign-off |
| 7. Launch & Handover | Production deployment, handover documentation, SLA or maintenance agreement, training | 5% | Confirm launch timing (ideally a low-traffic window), assign an ops point of contact, attend training |
The seven stages add up to 100% of the timeline, and development is almost always the largest share — it's where every earlier decision from architecture and design gets turned into a system that actually runs, tested and debugged module by module.
How do you turn these percentages into actual weeks? Pick a total duration for the project (6-12 weeks for an MVP, 3-6 months converted to weeks for an enterprise build), then multiply by each stage's share. As an anonymized composite example, not a specific client: for a 10-week MVP, that works out to roughly 1 week of discovery, 1.5 weeks of planning and architecture, 1.5 weeks of design, 3.5 weeks of development, 1.5 weeks of testing and QA, half a week of UAT, and half a week of launch handover. Real projects rarely split this cleanly, but working backward from these percentages is a fast way to sanity-check a vendor's proposed schedule — if a vendor compresses development down to 2 weeks while stretching discovery to 3, that usually signals they don't yet have a firm grip on scope, or they're using the discovery period as slack rather than genuinely needing that long to nail down requirements.
Agile vs. Waterfall: Which One Should You Choose?
The seven stages don't change, but whether you run them Agile or Waterfall changes how each one is executed and how much ongoing input the client side needs to provide. According to Aha.io's comparison of Agile and Waterfall, Waterfall locks down scope and requirements early, but cost and timeline are the parts that tend to move — projects following this model are "rarely delivered on time." Agile flips that: it keeps time and cost relatively fixed while letting scope adjust each iteration, using continuous user feedback to spread out risk instead of concentrating it at the end.
| Dimension | Agile | Waterfall |
|---|---|---|
| Flexibility | High — scope adjusts based on feedback from each iteration | Low — scope is locked during discovery; mid-project changes are costly |
| Timeline predictability | Time and cost stay relatively stable; scope flexes by priority | Detailed upfront schedule, but any requirement change tends to push the launch date back |
| Client involvement needed | High — each sprint (usually 1-2 weeks) needs client review and feedback | Low — concentrated mainly at discovery and final acceptance |
| Best-fit project type | Products that evolve with market feedback, MVPs, internal tools | Projects with clear, fixed requirements — regulatory systems, legacy replacements |
| Risk profile | Iterative delivery surfaces gaps early; risk is spread out | Requirement mismatches surface late; the cost of fixing them rises the further along the project is |
In practice, most custom software projects for Taiwan SMEs end up as a hybrid: Waterfall-style planning during discovery and architecture, where scope and milestones get locked down, followed by Agile-style two-week delivery cycles once development starts — combining timeline predictability with room to adjust. As an anonymized composite example: for a manufacturing client rolling out a new ERP shipment module, the regulatory filing format and the existing system's integration spec were already fixed at the start of the project, so the team ran planning as Waterfall — locking down field mappings and filing logic in one pass. Development, though, still shipped in two-week iterations, so the client could check filing output against each completed module right away and catch data-mapping gaps early, instead of discovering them only during final integration testing at the very end of the build.
Discovery: The Stage That Shapes Everything After It
Discovery is the stage most often compressed under time pressure, and the one with the longest-reaching consequences. Plan for at least 2-3 rounds of interviews: a broad session to understand the business context and pain points, a detail-focused session on the priority feature modules and edge cases, and a final pass to catch anything missed. The output is a requirements spec covering the feature list, priority order, and whether the system needs to integrate with existing systems — ERP, payments, third-party APIs.
This stage takes up 10% of the timeline because it determines the scope and difficulty of the six that follow. As an anonymized composite example: for a manufacturing client with around 50 employees, confirming during discovery that shipment data needed to sync with an existing ERP let the architecture stage plan the data-sync mechanism up front — instead of discovering an incompatible interface halfway through development and having to redesign the architecture mid-build.
Planning & Architecture: Turning Requirements into a Technical Blueprint
Planning and architecture takes the requirements spec and turns it into a technically executable blueprint — a system architecture diagram, tech stack decisions, and a database schema draft. According to IBM's overview of the software development lifecycle, phases including planning, analysis, design, implementation, testing, deployment, and maintenance "are often interconnected and might be completed sequentially or in parallel depending on the development model an organization uses" — which is part of why most teams in 2026 run these stages iteratively rather than as fully isolated blocks.
What the client needs to do here is confirm that the architecture direction and tech stack fit existing IT constraints — server standards, security requirements — and sign off on the milestone schedule so every later stage has a clear checkpoint. If the project involves integrating with existing systems, such as an ERP or payment gateway, this is the stage to get integration documentation or test credentials from the client's IT contact, rather than discovering a mismatched spec once development is already underway.
Design and Development: The Two Most Time-Intensive Stages
Design and development together account for 50% of the timeline — the largest combined share of the seven stages. Design starts with wireframes to confirm page-level logic, then moves to high-fidelity mockups and an interactive prototype so the client can preview the interface and flow before any code is written. Client turnaround directly affects the schedule here — we recommend feedback on mockups within 24-48 hours, since each extra round of revisions that drags past a week compounds quickly.
Development is where those mockups and the architecture become a working system. A professional team typically delivers a working, testable module every two weeks, so the client can keep confirming direction and catching gaps early rather than only seeing the finished product at the end. That's also why development, despite having the largest timeline share, tends to feel lower-risk in practice than its size suggests — problems surface within each two-week cycle instead of accumulating until the very end.
Testing, Acceptance, and Launch: Keeping the Schedule on Track
Testing and QA cover functional, integration, and performance testing, aiming to catch and fix predictable errors before formal acceptance begins. The client's role here is providing de-identified real test data and helping confirm edge cases — unusual quantities, malformed input — since a development team can rarely anticipate every real-world scenario on its own.
UAT is only about 5% of the timeline, but it's the stage most likely to determine whether launch happens on schedule: real end users run through actual business workflows to confirm the system genuinely supports day-to-day work, rather than the development team signing off on its own build. Issues found during UAT should be triaged — anything blocking a core workflow gets fixed before launch, while polish items or secondary features can move into the first post-launch iteration instead of indefinitely delaying go-live.
Launch is best scheduled during a low-traffic window, with a rollback plan ready in case something major surfaces, so you can revert to the previous system quickly and limit the operational impact. Handover documentation and SLA terms should be finalized at this stage too — not negotiated after the fact, which leaves post-launch bug fixes with no agreed response time.
Common Mistakes and Red Flags
These are the process mistakes we see most often derail an otherwise well-scoped project:
- Quoting a price after a single discovery meeting, then absorbing scope creep throughout development as requirements keep surfacing
- Letting design mockups go through more than 3 rounds of revision without finalizing, which eats directly into development time
- Skipping clear acceptance criteria for each development iteration, so misalignment isn't caught until UAT
- Having the development team "accept" its own work instead of involving real end users in UAT, then discovering the workflow doesn't match how people actually work
- Scheduling launch during a peak traffic period with no rollback plan, leaving no fast way back if something breaks
- Negotiating the maintenance contract and SLA only after launch, so post-launch fixes have no agreed response time
- Slow client-side turnaround on design feedback or test data, which caps how fast even an efficient development team can move
These seven mistakes share a common root: most aren't caused by weak technical execution, they're caused by a process step getting skipped or compressed under time pressure. When evaluating a vendor's proposal, ask directly how they'd handle these situations — "what's your standard for deciding whether a UAT defect blocks launch or ships in the next iteration," or "what happens if design mockups go past three rounds of revision without sign-off." Questions like these usually reveal more about a vendor's actual project management maturity than the quoted price does, and they surface upfront whether you and the vendor define "delay" and "scope change" the same way.
Next Steps
Breaking the process into seven stages with clear deliverables and timeline shares gives you a basis for budgeting and scheduling before a project starts — and a way to check whether a vendor's proposal is actually planned out, rather than a single lump-sum duration. If you're evaluating a custom software project, see our Custom Software Development Services page for how we scope and deliver against these seven stages, or our Process & Pricing page to compare typical timelines and pricing across project sizes.