What’s Actually Included in Web Application Development (From Idea to Launch)

Most clients commissioning their first web application think the work is mostly “writing code.” It is — about half of it. The other half is understanding the problem, designing the experience, testing what was built, deploying it safely, and supporting it once real users arrive. Each of those parts has a concrete cost, a concrete timeline, and a concrete impact on whether the product actually works in the world.

This post breaks down the full lifecycle, phase by phase: what happens, who’s involved, what you actually have at the end, and where the most expensive mistakes tend to hide. If you’re about to commission a web application — or you’re in the middle of one and trying to make sense of where the budget is going — this is the map.

The full process at a glance

A standard web application moves through six clear phases:

The percentages aren’t a strict rule, but they’re a useful sanity check. Projects where design is squeezed to 5 % usually look like a template. Projects where QA is squeezed to 3 % ship with bugs in production. If a quote you receive deviates wildly from these proportions, ask why.

Phase 1: Discovery and specification

What happens: the problem gets defined, the users are identified, the core flows are mapped, the minimum feature set is agreed, and — equally important — the explicit list of what you’re not building gets written. Foundational technical choices (frontend framework, backend, database, hosting) get sketched.

Who’s involved: you (as product owner), product manager or technical lead from the agency, sometimes one engineer.

What you actually have at the end:

• A scope document (3 – 10 pages)
• A map of the core user flows
• A “not doing” list for v1
• A high-level technical architecture (a brief, not a treatise)
• A realistic estimate of duration and cost

Duration: 1 to 3 weeks depending on how clear the idea is.

The most common mistake: skipping this phase “to save time.” The week saved here usually turns into 4 to 6 weeks of later problems. The other common mistake is the opposite — discovery that drags on for two months. If discovery takes more than three weeks, the issue isn’t research. It’s avoidance of decisions.

Phase 2: UI/UX design

What happens: wireframes (rough layouts), then high-fidelity UI design with the visual identity applied, then a clickable prototype that simulates the core flows. Design typically goes through 2 to 3 iterations.

Who’s involved: UI/UX designer, you (for review and decisions), product manager.

What you actually have at the end:

• Wireframes for all key screens
• High-fidelity UI design for the primary screens (in Figma)
• A clickable prototype
• A small design system (components, colours, typography) — minimal, not exhaustive

Duration: 2 to 6 weeks depending on screen count and complexity.

The most common mistake: designing every screen before development starts. Development can begin once the core screens are done. Secondary screens get designed in parallel with the build.

A second trap: testing the design only with your team rather than with real users. Five colleagues nodding “looks great” doesn’t compensate for one real user getting lost in your onboarding flow. The clickable prototype exists specifically so you can put it in front of actual potential users before the team writes a line of code.

Phase 3: Development

The biggest block. Two parallel tracks: frontend (what the user sees) and backend (the logic, database, and API connecting everything).

Backend development

• Infrastructure setup: server, database, deployment pipeline
• Database modelling: how data is stored and related
• API: the endpoints the frontend calls for data
• Business logic: the rules of how the system behaves (authentication, payments, processing)
• Integrations: connections to external systems (Stripe, email providers, CRM)
• Security: input validation, rate limiting, protection against the most common attacks

Frontend development

• Component development: building the UI elements based on the design
• Screen implementation: assembling components into functional pages
• API integration: fetching and submitting data
• State management: how the application remembers context (logged-in user, cart, filters)
• Responsiveness: behaviour across different screen sizes
• Performance optimisation: load speed and runtime efficiency

How development actually flows

Development is typically organised into two-week sprints:

• Sprint 0 (1 – 2 weeks): environment setup, deployment pipeline
• Sprint 1: core user flow end to end (authentication, primary functionality)
• Sprint 2: secondary features, integrations
• Sprints 3 – 5+: additional functionality, polish, optimisation

At the end of each sprint, you have a working version you can test. This matters — a project that can’t show progress in a two-week sprint is a project with structural issues.

Total phase duration: 6 to 24 weeks depending on scope.

The most common mistake: trying to build everything at once instead of shipping the critical path first. If the core flow doesn’t work, nothing else matters.

Phase 4: QA and testing

What happens: systematic testing of every feature, every user flow, every edge case. Not just “does it work?” — also “what happens when the user enters nothing, when their internet drops, when the third-party service fails, when they paste nonsense into the form?”

Types of testing:

• Functional: does each feature behave as specified
• Cross-browser and cross-device: Chrome, Safari, Firefox, mobile, tablet
• Performance: how fast pages load, how the system behaves under load
• Security: input validation, authentication, authorisation, common attack vectors
• Accessibility: keyboard navigation, screen readers, contrast
• User Acceptance Testing (UAT): you and your team try the app like real users would

Who’s involved: a QA engineer (if the team has one dedicated) or developers in rotation, you and your team for UAT.

What you actually have at the end:

• A tested application with a prioritised bug list
• Critical bugs fixed
• Documented minor issues that don’t block launch
• Performance benchmarks under expected load

Duration: 1 to 3 weeks.

The most common mistake: treating QA as a checkbox rather than a real quality gate. If QA gets compressed from 12 days to 3 because of schedule pressure, the critical bugs that should have been caught here surface in the first week of production — and cost 5 to 10 times more to fix under live-user pressure.

Phase 5: Deployment and launch

What happens: the application gets moved from staging to production. Final configuration, monitoring, backups, and alerting are set up. Your team gets trained, documentation is finalised.

Concrete activities:

• Production environment configuration or PaaS setup
• DNS, SSL, email configuration
• Monitoring (uptime, error tracking, logging)
• Backup procedures and recovery testing
• Performance baseline measurement
• Internal training for your team and administrators
• User documentation or onboarding flow
• Launch communication plan

Duration: 1 to 2 weeks.

The most common mistake: treating deployment as “just flipping a switch.” Real production behaves differently from staging — real traffic, real data, real users. A week spent on launch preparation typically saves three weeks of post-launch firefighting.

Phase 6: Post-launch support

What happens: the first 30 to 90 days after launch are typically a “warranty period” — the agency fixes any bugs they introduced, free of charge. After that, you may move into a retainer — a monthly fee for a defined number of hours of support, minor changes, and continued development.

What’s covered:

• Fixing bugs that surface in production
• Minor changes and optimisations
• Performance tuning based on real traffic
• Security updates
• Infrastructure scaling as needed

Duration: depends on the arrangement. Standard warranty period is 30 to 90 days. Retainers are typically 6 to 12 months with renewal options.

The most common mistake: thinking the project ends at launch. Real products are never “done.” Applications without a support plan typically become unstable within 6 to 12 months because nobody’s running security updates, responding to performance drift, or fixing minor bugs before they grow into bigger ones.

The less visible parts (that matter just as much)

There are three activities that run across the entire project, often underestimated:

Project management

Someone has to coordinate: plan sprints, run meetings, escalate blockers, keep the budget and timeline in check. On smaller projects, this falls to the tech lead. On larger ones, you have a dedicated project manager. Without this role, projects typically slip 30 to 50 % without any specific “bad event” — just slow loss of focus.

Communication with you

The part that rarely shows up clearly on an invoice but consumes 10 to 15 % of the team’s time. Weekly updates, demos, prep for questions, documenting decisions. It’s not bureaucracy — it’s the reason you, as the client, know what’s happening at all.

Documentation

Technical documentation (how the system works), user documentation (how a user uses the application), runbook for your team (what to do when something breaks). These are produced throughout the project, not at the end. Documentation written at the end is usually documentation that doesn’t get written — and that becomes a problem 12 months later when someone new has to take over the system.

Risk identification

A good team actively looks for risks — integrations that might slip, assumptions that haven’t been verified, performance issues that might emerge. This is continuous, not a separate phase.

A real example: a $30,000 web application in 14 weeks

To make the percentages concrete, here’s how costs and time typically distribute for a standard B2B application with a $30,000 budget and a 14-week target:

The numbers shift with the specifics, but the proportions tend to hold across similar projects.

The bottom line

Web application development is six overlapping phases: discovery, design, development, QA, deployment, and post-launch support. Development itself is only half the work. The other phases aren’t bureaucracy — they determine whether the product actually works in the hands of real users, how much you’ll pay later to fix what was missed, and how long the application will run before needing a major rebuild.

The biggest pitfalls: skipping discovery to “save time,” over-designing before development starts, squeezing QA under schedule pressure, treating deployment as trivial, and ignoring the support plan. Each of those mistakes costs — typically 2 to 5 times more than what you tried to save by cutting them.

The smartest framing is to look at the entire lifecycle, not just the build cost. An application isn’t done when it ships. It’s only just begun delivering value — and the next year, two, three are where the actual return on investment compounds.

Considering development and want a clearer picture of the process? A short discovery conversation lets us walk you through the full lifecycle for your specific project and give you a realistic estimate of scope and duration. Get in touch. More about how we approach development on the Web Application Development page.