# The Software Development Process: 7 Stages Explained

> A custom software project runs through 7 stages from discovery to launch. In 2026, development alone typically takes 35% of the total timeline.

- URL: https://noise-and-signal.com/en/insights/software-development-process-guide
- Author: 翁睿承 (諾訊科技 Noise & Signal)
- Published: 2026-09-15
- Tags: Custom Software
- Language: en

---
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](https://www.aha.io/roadmapping/guide/agile/agile-vs-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](https://www.ibm.com/think/topics/software-development), 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](https://noise-and-signal.com/en/services/custom-software) page for how we scope and deliver against these seven stages, or our [Process & Pricing](https://noise-and-signal.com/en/process) page to compare typical timelines and pricing across project sizes.

## FAQ

### How long does the entire software development process take?

It depends on scope — an MVP typically launches in 6-12 weeks, while a full enterprise system usually takes 3-6 months. The 7-stage timeline shares in this guide let you convert either range into weeks per stage.

### How many discovery interviews should we expect?

Plan for at least 2-3 rounds — one broad session to understand the business, one to confirm feature-level detail, and one to catch anything missed. A single meeting rarely surfaces the full requirement set, which is the most common cause of scope creep later.

### Why does the development stage take up 35% of the timeline?

Development takes up roughly 35% of the timeline because this is where architecture and design get turned into working, tested code across every module — the most labor-intensive of the seven stages. Teams typically deliver in two-week iterations here, which is also why client responsiveness matters most during this stage.

### Is Agile or Waterfall faster?

Neither is universally faster — it depends on the project. Agile keeps cost and timeline more stable while scope adjusts each 1-2 week sprint; Waterfall can work well when requirements are genuinely fixed, since thorough upfront planning during the first 25-30% of the timeline pays off in that case.

### How long does UAT (user acceptance testing) take?

Usually 1-2 weeks, depending on system complexity, with real end users running through actual business workflows before sign-off. It is only about 5% of the total timeline but is the stage most likely to determine whether launch happens on schedule.

### How long after launch counts as a proper handover?

We recommend a 2-4 week intensive monitoring window after go-live, backed by a formal maintenance contract. Treating launch day itself as the finish line is a common mistake, since early post-launch fixes need a clear SLA in place to define response times.

### Which stage most often causes delays?

Based on our 2026 project experience, discovery and UAT — roughly 10% and 5% of the timeline respectively — are the stages most often delayed by slow client-side sign-off or feedback. Development, despite taking the largest share at about 35%, tends to see fewer surprises because its two-week iterations surface problems early instead of at the end.

### How can we tell if a vendor's process is actually solid?

Ask them to break the proposal into the same 7 stages with deliverables and a timeline share for each, rather than accepting a single lump-sum duration. A vendor that can walk through this breakdown in detail is usually the one with a more mature delivery process.