The standard web app development process runs through seven phases: discovery, planning, design, development, QA, deployment and post-launch, each with its own gate and deliverable. A small project moves through this in a few weeks; a complex one takes months. The riskiest handover sits between design and development, where unclear specs quietly turn into expensive rework.
- Before development begins, approve final wireframes, the data model, and the API contract; written acceptance criteria keep version one scope verifiable.
- Automated unit, integration, contract, and user journey tests catch specified failures, while real user monitoring reveals performance problems across actual devices and connections.
- For public facing or public sector services, build accessibility in from design and use WCAG 2.2 AA, with a current accessibility statement and periodic audits.
- Choose an OWASP ASVS level based on stored data and potential harm; automate code, dependency, and secrets scans, and arrange penetration testing for payment apps.
Table of Contents
- The web app development lifecycle, phase by phase
- Scoping and estimates: how to avoid requirement drift and set realistic timelines
- Design outputs: wireframes, prototypes, accessibility and developer handover
- Development practices: front end, back end, APIs and integration patterns
- Testing strategy: layered automation, accessibility checks and real-user monitoring
- Deployments, CI/CD and operational readiness
- Core Web Vitals and performance workstreams: measuring and improving LCP, INP and CLS
- Security baseline and compliance: integrating OWASP ASVS and privacy considerations
- Practical toolmap: tools for each phase of the build
- Post-launch routines: monitoring, iteration, and support retainers
- Agency-proven checklist and examples from TTOY Digital
- Three lessons from building web applications
- Ready to scope your own web application?
- FAQ
- Sources
The web app development lifecycle, phase by phase
Every phase has an owner, a deliverable and a question that has to be answered before anyone moves forward. Skip that question and you pay for it later, usually in the development phase, when the bill for ambiguity always lands.
Discovery is where we figure out what we’re actually building and why. This means talking to the people who’ll use the thing, not just the person paying for it. A good discovery phase produces:
- Interview notes from real users, not assumptions about them
- A written statement of the business goal the app needs to hit
- Acceptance criteria for the minimum viable product (MVP), so everyone agrees what “done” looks like
Planning and architecture turns those goals into technical decisions. Someone has to choose a tech stack, sketch how data will flow through the system and put a number on the timeline and budget. This is also where system diagrams earn their keep: a simple diagram showing how the front end, back end and database talk to each other saves hours of confused conversation later.
Design translates requirements into something people can actually look at and react to. Wireframes come first, low on detail and quick to change. Then interactive prototypes, which let you test the flow before a single line of code exists. Accessibility checks belong here too, not bolted on at the end, along with a design system: a shared library of components and design tokens that keeps buttons, colours and spacing consistent across every screen.
Development splits into front-end work (what people see and click) and back-end work (what stores and processes their data). The two sides meet at the API, the contract that defines how they exchange information. Getting that contract agreed early avoids a lot of “that’s not what I expected” moments.
QA and testing is where automated checks run alongside manual review. This includes:
- Unit tests that check individual functions in isolation
- Integration tests that check those functions working together
- End-to-end tests that simulate a real user’s journey
- Accessibility and security checks run against defined standards
- Real user monitoring (RUM) once live, to see how the app behaves for actual visitors on actual devices
Deployment moves the app from a staging environment, where it’s tested under conditions close to production, into the live environment. A continuous integration and continuous delivery (CI/CD) pipeline automates this, and a rollback plan means a bad release can be undone quickly rather than panicked over.
Post-launch is ongoing: monitoring for errors and slow performance, triaging a backlog of fixes and new features, and keeping the thing secure and fast as it ages. Many teams treat launch as the finish line. It’s closer to the starting gun.
Throughout all seven phases, stakeholder communication matters as much as the technical work. Short, regular check-ins, shared documents rather than buried email threads, and a single source of truth for decisions keep a project from drifting. Version control (almost always Git) and a sensible branching strategy, such as feature branches merged through pull requests, keep multiple people working on the same codebase without stepping on each other.
Scoping and estimates: how to avoid requirement drift and set realistic timelines
Requirement drift, where what gets built slowly diverges from what was agreed, is the single most common reason web app projects run over budget and past deadline. The fix isn’t more meetings. It’s a proper scoping process before anyone touches code.
A paid discovery or scoping workshop, run over a few days or a couple of weeks, forces the hard questions early: who’s using this, what does success look like, what’s genuinely in scope for version one. The output should be a written scope document with acceptance criteria attached to every feature, so “it should work well” becomes something you can actually check against.
Phase gates make this stick. Before development starts, you need sign-off on:
- Finalised wireframes that won’t change once coding begins
- An agreed data model showing what information the app stores and how
- An API contract defining how front end and back end talk to each other
For estimating effort, two methods dominate. Story points rank tasks by relative complexity rather than hours, useful once a team has a few sprints of history to calibrate against. T-shirt sizing (small, medium, large) is rougher but faster, often used early when detail is still thin.
Smaller projects typically take a few weeks, medium-sized ones a few months, and large, multi-feature platforms can take half a year or longer, depending on complexity. These bands shift with team size and how settled the requirements are, which is exactly why the scoping document matters: it turns “it depends” into a specific, agreed answer. Our own scoping checklist for small businesses walks through this in more detail.
Pro Tip: Write acceptance criteria as a checklist your client could tick off themselves, not as a paragraph of prose. If they can’t verify it, it isn’t a criterion.
Design outputs: wireframes, prototypes, accessibility and developer handover
Good design work isn’t about making things pretty. It’s about removing ambiguity before it becomes a developer’s problem.
The sequence that works best starts with low-fidelity wireframes, basic boxes and labels showing where things sit on a page. These evolve into interactive prototypes that let you click through a flow as if it were real. Testing those prototypes with a handful of representative users, not just the project team, surfaces confusion while it’s still cheap to fix.
A design system pays for itself quickly. Once you’ve defined your buttons, type styles, spacing rules and colours as reusable components, every new screen takes less time to design and build, and the whole app feels consistent rather than stitched together from different moods.
Accessibility has to be part of this from the start, not a review at the end. For any service with a public-sector angle or ambitions to serve a wide audience well, Gov sets WCAG 2.2 AA as the practical benchmark, alongside publishing an accessibility statement and running periodic audits. A sensible accessibility checklist covers:
- Colour contrast that meets AA thresholds, checked at design stage, not after launch
- Keyboard navigation for every interactive element
- Proper heading structure and alt text planned into content, not added as an afterthought
- A published accessibility statement that’s kept current
There’s a commercial reason to take this seriously too. Accessibility and SEO performance are closely linked, since many of the fixes that help screen reader users (clean heading structure, descriptive links, sensible page titles) are the same things search engines reward.
Developer handover should leave nothing to guesswork: annotated components showing spacing and states, exported design tokens, image assets in the right formats, and written interaction specs for anything that moves or changes on click. Field data from the Core Web Vitals framework sets clear thresholds for a well-performing app, and performance expectations belong in the handover brief, not discovered after launch.
Development practices: front end, back end, APIs and integration patterns
The technical choices made here shape how the app feels to use and how easily it can grow later.
For the front end, the main decision is between a single-page application (SPA), server-side rendering (SSR) or a hybrid of the two. An SPA, where the browser loads once and swaps content dynamically, suits highly interactive tools like dashboards. SSR, where each page is rendered on the server before it reaches the browser, tends to load faster on first visit and is often better for content-heavy sites that need to rank well in search. Hybrid frameworks let you render some pages on the server and handle others dynamically, which is increasingly the default choice for anything that’s both content-rich and interactive.
On the back end, three patterns cover most needs:
- A monolith, where all the logic lives in one codebase, which is simple to build and deploy for smaller apps
- Modular services, splitting the app into separate pieces by function, useful once a team or feature set outgrows a single codebase
- Serverless functions, which run on demand without managing a server, often a good fit for infrequent or spiky workloads
Data storage choices follow from this: a relational database suits structured data with clear relationships, while a document store fits looser, evolving data shapes. Most apps use a mix once they mature.
API design deserves real thought rather than being an afterthought of the back-end build. A contract-first approach, where you define the API’s shape before writing the code behind it, keeps front-end and back-end teams working in parallel without constant renegotiation. Versioning matters too: once an API has real consumers, breaking changes need a new version rather than quietly altering the old one, so existing integrations don’t break overnight.
Code health is easy to neglect under deadline pressure and expensive to recover later. Linting catches style and logic issues before they reach review. Dependency management, keeping third-party libraries updated and auditing them for known vulnerabilities, avoids both security gaps and the slow accumulation of outdated packages that eventually force a painful rewrite. Performance constraints should sit in the back of every decision: a feature that works beautifully in testing but loads three seconds of JavaScript on a mobile connection isn’t actually finished.
Testing strategy: layered automation, accessibility checks and real-user monitoring
A good testing strategy answers one question at each layer: what, specifically, could go wrong here, and how would we know?
- Unit tests check individual functions in isolation and catch logic errors cheaply, before they ripple into anything else
- Integration tests confirm that components work together correctly, catching the gaps that unit tests miss by design
- Contract tests verify that an API still behaves the way its consumers expect, useful whenever front end and back end are built by different people or teams
- End-to-end tests simulate an actual user journey through the whole app, the slowest tests to run but the closest to reality
These should run automatically in a CI pipeline on every push, with releases gated on a minimum pass rate rather than relying on someone remembering to test manually.
Automated tests only tell you about the scenarios you thought to write. Real user monitoring (RUM) fills that gap by capturing what’s actually happening for visitors in the field, including interaction responsiveness (INP), which lab testing alone can’t fully replicate, since it misses the full range of devices and connection speeds people genuinely use, as web.dev’s guidance on optimising INP sets out. Field data flags the slow interaction; lab tools then help you reproduce and fix it.
Accessibility testing needs the same layered approach: automated scanners catch the easy, structural issues quickly, manual sampling catches what scanners miss (focus order, meaningful alt text, logical reading order), and testing with people who actually use assistive technology catches what nobody else will.
Pro Tip: Run your heaviest end-to-end test suite nightly rather than on every single commit. It keeps feedback loops fast during the day without losing full coverage.
Deployments, CI/CD and operational readiness
Getting code live safely is a different skill from writing it, and it’s where a lot of otherwise solid projects come unstuck.
A CI/CD pipeline automates building, testing and releasing code, so every change follows the same checks rather than depending on someone remembering the steps. Release strategy matters here too:
- Blue/green deployment runs two identical environments and switches traffic between them, making rollback nearly instant if something’s wrong
- Canary releases send new code to a small slice of users first, catching problems before they affect everyone
- Feature flags let you turn a feature on or off without a new deployment, useful for gradual rollouts or quick fixes
Hosting choices trade convenience against control. A managed platform-as-a-service handles infrastructure for you at the cost of some flexibility. Containers, packaged units of an app and its dependencies, offer more portability between environments. Serverless hosting suits unpredictable or low-frequency workloads well. Traditional virtual machines still make sense when you need full control over the environment.
Once live, observability keeps you honest: metrics (numbers like response time and error rate), logs (what actually happened, in order) and tracing (following a single request through the whole system) together tell you what’s going wrong before users complain.
A short runbook, a written set of steps for common incidents, and a clear escalation path (who gets called, in what order) turn a stressful outage into a manageable one.
Core Web Vitals and performance workstreams: measuring and improving LCP, INP and CLS
Performance isn’t a nice-to-have bolted on near launch. It’s measured against three specific thresholds, and missing them has a direct, measurable cost.
Google’s Core Web Vitals define key performance benchmarks:
| Metric | What it measures |
|---|---|
| LCP (Largest Contentful Paint) | How quickly the main content loads |
| INP (Interaction to Next Paint) | How responsive the page feels to clicks and taps |
| CLS (Cumulative Layout Shift) | How much the page shifts visually as it loads |
These metrics are generally assessed across the majority of user visits to reflect real-world performance, not just optimal test scenarios.
Field data, gathered through RUM or the Chrome UX Report, shows what real visitors actually experience. Lab testing, run under controlled conditions, then helps you reproduce and diagnose a specific problem flagged by that field data.
Common effective improvements include image optimisation, breaking up long JavaScript tasks, code splitting to load only necessary parts, and reserving space to prevent layout shifts.
We’ve covered the practical side of this in more depth in our guide to Core Web Vitals for webmasters, including how slow pages translate into lost conversions for small business sites.
Security baseline and compliance: integrating OWASP ASVS and privacy considerations
Security that gets added as a final step before launch is security that gets skipped when the deadline is tight. The better approach treats it as a standing requirement, checked throughout.
The OWASP Application Security Verification Standard (ASVS) gives this structure. It organises security requirements into three levels: Level 1 for baseline protection suitable for most apps, Level 2 for apps handling sensitive data, and Level 3 for the highest-risk systems. Picking the right level depends on what the app actually stores and who could be hurt if it were compromised.
Day-to-day, this translates into automated tooling built straight into the CI pipeline:
- Static application security testing (SAST) scans code for known vulnerability patterns before it ships
- Dependency scanning flags third-party libraries with known security issues
- Secrets scanning catches API keys or passwords accidentally committed to the codebase
External penetration testing, where specialists actively try to break the app, is worth scheduling once the app handles meaningful user data or payments, and ASVS gives a practical starting point for scoping exactly what that test should cover.
Privacy by design belongs right back at the requirements phase, not treated as a compliance afterthought. Deciding what data you actually need to collect, and how long you keep it, is far easier to settle before you’ve built around the alternative.
Practical toolmap: tools for each phase of the build
Matching tools to team size and budget matters more than chasing whatever’s newest. Here’s a practical breakdown by phase:
- Design and prototyping: tools for wireframing and interactive prototypes, paired with a shared component library that keeps the design system consistent across every screen
- Front-end frameworks: component-based libraries for building interactive interfaces, often paired with a meta-framework that handles rendering strategy (SPA, SSR or hybrid)
- Back-end frameworks and server options: a runtime and framework suited to your team’s existing skills, plus a database engine chosen to match your data shape
- CI/CD and containers: pipeline tools that automate testing and deployment, often paired with container tooling for consistent environments across development and production
- Hosting: managed platforms, container orchestration or serverless platforms, chosen against the trade-offs covered in the deployment section above
- Monitoring and RUM: tools that capture field performance data and error rates in production, feeding straight back into the Core Web Vitals work covered earlier
- Testing and accessibility: automated test runners for unit, integration and end-to-end layers, plus accessibility scanners for catching structural issues early
The right combination depends far more on your team’s existing skills and your budget than on any single tool being objectively best. A team that knows one stack well will usually ship faster in it than in an unfamiliar “better” one.
Post-launch routines: monitoring, iteration, and support retainers
Launch day is the start of the app’s working life, not the end of the project.
A healthy post-launch routine starts with a clear service level agreement (SLA): how quickly issues get acknowledged, and what support hours actually cover. Alongside that, a maintenance schedule for routine work, security patches, dependency updates, performance checks, keeps small problems from becoming big ones.
Backlog prioritisation should draw from two sources: direct user feedback and monitoring signals (error rates, slow pages, abandoned flows). Features that sound good in a meeting rarely compete with fixes that monitoring shows are actively costing users.
As traffic grows, capacity planning becomes relevant: knowing at what point your current hosting setup needs scaling up, and having a plan for that before it becomes urgent, rather than during an outage.
Typical post-launch support covers:
- Scheduled monitoring reviews, often monthly, checking performance and error trends
- A rolling maintenance schedule for security patches and dependency updates
- A backlog review process that weighs user feedback against monitoring data
- An agreed incident process for anything urgent, with clear ownership
Retained support, rather than one-off fixes, tends to keep an app in better shape over time simply because someone is consistently watching it rather than reacting only when something breaks.
Agency-proven checklist and examples from TTOY Digital
We run every web application project through a scoping process before writing a line of code, because the apps that go smoothly are almost always the ones where expectations were pinned down early.
Our checklist starts with a paid discovery phase: understanding what the business actually needs, defining the MVP in writing and agreeing acceptance criteria that both sides can point to later if there’s ever a dispute about scope. We use our own web app scoping checklist as the backbone of that conversation with every client.
One practical example of what this looks like in practice is a CRM we built to pull WhatsApp, email and other lead channels into a single workflow rather than leaving a small business owner checking four different inboxes. It’s a useful illustration of what a bespoke web application can solve when it’s scoped around a genuine daily frustration rather than a generic feature list.
If you’re briefing an agency yourself, a few questions separate a solid process from a vague one:
- What does your discovery phase actually produce, in writing?
- Who signs off on wireframes and data models before development starts?
- What does your testing process cover, and how is performance measured after launch?
- What happens after launch: is there a support retainer, and what does it include?
Pro Tip: Ask to see a sample scope document from a previous project before you sign anything. A vague answer here usually predicts a vague project.
Three lessons from building web applications
Requirement drift is the single biggest reason projects run late or over budget, and the fix is almost boringly simple: phase gates. Get sign-off on wireframes, the data model and the API contract before development starts, and most of the expensive surprises disappear before they can happen.
Performance and security aren’t launch-week tasks. They need to be part of every sprint, not a checklist run once at the end, because retrofitting either into a finished app costs far more than building them in from the start.
Automated tests tell you the app works the way you specified. Real user monitoring tells you whether that specification matched reality. You need both, because neither one alone gives you the full picture.
— Chris
Ready to scope your own web application?
If you’re staring at a list of features and no clear idea how to turn it into a working plan, that’s exactly what a scoping workshop is for. We run these as a paid discovery engagement, and what you get back is concrete: a written scope document, a realistic timeline and a clearly defined MVP you can actually hold us to.
From there, our web application development service covers the build itself, bespoke to your workflows rather than templated. If lead management across WhatsApp, email and other channels is part of the problem you’re solving, our CRM plans are worth a look alongside it.
- Scoping workshop: discovery, acceptance criteria and MVP definition
- Bespoke build: front end, back end and API work tailored to your business
- Ongoing support: maintenance and monitoring once you’re live
Get in touch through our web applications page to talk through what you’re trying to build.
FAQ
What are the seven stages of app development?
The standard stages are discovery, planning and architecture, design, development, QA and testing, deployment, and post-launch support. Each stage has its own deliverable and a sign-off point before the next one starts, which keeps scope from drifting as the project moves forward.
Can I learn web development in three months?
You can learn the basics of front-end web development, such as HTML, CSS and some JavaScript, in a few months with consistent practice. Building a complete, production-ready web application, with a solid back end, testing and security baked in, typically takes considerably longer to learn properly.
Can ChatGPT create a web app?
ChatGPT and similar tools can generate code snippets, scaffold simple components and speed up parts of the development process. They don’t replace the planning, architecture decisions, testing and security review a working application needs, so human oversight through the full process is still necessary.
Is AI replacing web developers?
AI tools are changing parts of the job, particularly repetitive coding tasks, but the planning, architecture, testing and judgement calls that make a web app reliable and secure still need experienced people. Most teams now treat AI as a tool that speeds up certain tasks rather than a replacement for the role.
How long does web app development usually take?
Timelines vary with complexity: a simple tool might take four to eight weeks, a mid-sized app with integrations often runs three to five months, and a large, feature-rich platform can take six months to a year or more. A proper scoping phase at the start gives a far more accurate estimate than a generic rule of thumb.
