Commissioning custom software can feel opaque if you have not done it before. Weeks pass, demos appear, and it is not always clear what stage the project is in or what is expected of you. This article walks through the web application development process as most professional teams run it, stage by stage, with what each stage produces and where your input matters most.
Teams differ in terminology and some stages overlap, especially in agile projects where design, building and testing happen in repeated short cycles. But the underlying activities are the same.
Stage 1: Discovery
Purpose: understand the problem before proposing a solution.
The team interviews stakeholders, watches how work is done today and reviews existing tools, spreadsheets and documents. The aim is to find out who the users are, what slows them down, what the business needs to measure and what constraints exist (budget, deadlines, regulations, existing systems).
You receive: a summary of goals, users, key workflows, risks and open questions, often with a high-level estimate.
Your role: make the right people available, including the staff who will actually use the system daily, not just managers.
Stage 2: Requirements and scope
Purpose: agree what will be built first, in enough detail to estimate and test.
Requirements are often written as user stories, short statements such as "As a sales manager, I want to see overdue invoices by customer so that I can chase payments." Each story gets acceptance criteria: the specific conditions that must be true for it to count as done. Stories are then prioritised, and the first release is drawn around the must-haves.
You receive: a prioritised backlog or specification, and a scope for the first release.
Your role: decide priorities. Developers can tell you what something costs; only you can say what it is worth.
Stage 3: UX and interface design
Purpose: work out how people will move through the system before code is written.
Designers produce wireframes (simple layouts showing what goes where) and then clickable prototypes. Changing a prototype costs minutes; changing finished software costs days. For business applications, the priority is clarity: obvious navigation, sensible defaults, fast data entry and helpful error messages.
You receive: wireframes or prototypes for key screens, and a visual style.
Your role: test prototypes with real users and report confusion honestly.
Stage 4: Architecture and technical planning
Purpose: make the structural decisions that are expensive to change later.
This includes the technology stack, the database design, how the system will be hosted, how it will integrate with other software, how users will authenticate and how data will be backed up. Non-functional requirements are settled here too: expected number of users, response times, availability needs and security obligations.
You receive: an architecture outline and hosting plan. Ask for it in plain language if the first version is too technical.
Your role: share growth expectations and any compliance or data residency requirements.
Stage 5: Development in iterations
Purpose: build working software in small, reviewable increments.
Most teams work in sprints of one to three weeks. Each sprint takes a set of stories from the backlog, builds them, tests them and demonstrates them. Code is stored in version control (typically Git), reviewed by another developer before it is merged, and deployed automatically to a staging environment, a private copy of the application where you can try features before they go live.
You receive: regular demos and access to staging.
Your role: attend demos, try features on staging, and give feedback within the sprint. Feedback that arrives weeks later is much more expensive to act on.
Stage 6: Testing and quality assurance
Purpose: make sure the software works correctly, securely and reliably.
Testing happens continuously, not only at the end. Typical layers include:
- Automated unit and feature tests that check business rules, such as tax calculations, every time code changes.
- Manual exploratory testing by a QA specialist looking for edge cases.
- User acceptance testing (UAT), where your staff confirm the system supports their real work.
- Security checks: permission testing, dependency scanning and reviewing server configuration such as HTTP security headers, which you can inspect yourself with our HTTP header checker.
- Performance testing where high load is expected.
Your role: run UAT with real scenarios and sign off formally.
Stage 7: Data migration and launch
Purpose: move to the new system with minimal disruption.
Existing data is cleaned, mapped and imported, usually with several trial runs. A launch plan covers the production environment, domain and SSL configuration, monitoring and backups, user accounts and training. Many teams prefer a phased rollout, for example one branch or department first, so problems surface while they are still small.
You receive: the live system, user guides or training sessions, admin credentials and technical documentation.
Your role: plan the cut-over date around your business calendar and communicate it to staff.
Stage 8: Support, maintenance and improvement
Purpose: keep the system healthy and evolving.
The first weeks after launch usually bring small fixes and quick wins as real usage reveals gaps. After that, the application needs security updates, framework upgrades, monitoring and backups, plus new features as the business changes. Agree a support arrangement before launch so there is no gap.
How long does the whole web application development process take?
It depends on scope more than anything else. A focused internal tool may move through all stages in weeks; a multi-role business system typically takes months; and a platform is never really "finished". The surest way to shorten the timeline is a smaller first release, quick decisions and early, continuous feedback.
Warning signs during a project
- No working software to see after the first few sprints.
- No staging environment you can access.
- Testing planned only "at the end".
- Hosting, backups and handover not discussed until launch week.
If you are planning a project, our web application development page describes the kinds of systems this process typically delivers.
Key takeaways
- The process runs from discovery and requirements through design, architecture, iterative development, testing and launch to ongoing maintenance.
- Your most valuable contributions are prioritisation, timely feedback and user acceptance testing.
- Staging environments and regular demos keep the project visible and on track.
- Plan support and maintenance before launch, not after.