What actually happens in a web development project, week by week

The question we get asked most often at the start of a project isn't about cost or tech stack. It's some version of: 'What exactly are you going to be doing for the next 12 weeks?' It's a fair question, and most agencies don't answer it well. Here's our honest, week-by-week breakdown of what a full web project looks like from our side.

Week 1: Discovery and alignment

This is the most valuable week and the one most agencies rush. We spend week one doing three things: a structured kick-off session with every stakeholder, a full technical audit of any existing systems we'll be touching, and the creation of a shared project brief that both sides sign off on. The brief captures goals, success criteria, constraints, and anything that would cause the project to fail. If we can't agree on the brief, we don't build.

Weeks 2–3: Design and prototyping

Before writing a line of code, we build an interactive Figma prototype. Every screen. Every state. Every edge case. This takes longer than clients expect, but it saves an enormous amount of time later. When a client says 'I don't like where this is going' in week two, it's a 2-hour conversation. When they say the same thing in week eight, it's a 2-week rebuild.

• →Wireframes for all primary user journeys
• →Design system: colours, typography, spacing, component library
• →Interactive prototype with real navigation
• →Responsive designs for mobile, tablet, and desktop
• →Accessibility review built into the design phase

Weeks 4–10: Development sprints

Development happens in weekly sprints. Every sprint has a clear goal, a defined set of deliverables, and ends with a live demo. This is not a status update. This is functional software you can click through. If something's off, you tell us that week — not six weeks later.

What actually gets built in which order

• →Sprint 1: Project setup, CI/CD pipeline, hosting environment, authentication scaffolding
• →Sprint 2–3: Core data models, backend APIs, admin foundation
• →Sprint 4–5: Primary user-facing features, frontend components
• →Sprint 6–7: Secondary features, integrations (payments, emails, third-party APIs)
• →Sprint 8: Edge cases, error states, performance optimisation

Week 11: QA and hardening

We run a dedicated QA week before any project goes live. This isn't developers reviewing their own work. It's a structured testing process that covers functional correctness, performance benchmarks, accessibility compliance, security basics (no exposed API keys, no injection vulnerabilities, proper auth), and cross-browser/device testing. We produce a QA report that documents what was tested and what was found.

Week 12: Launch

Launch day is not a single moment. It's a coordinated process: database migrations, DNS cutover, cache warming, monitoring alerts, a 48-hour standby period. We do not launch on Fridays. We monitor for 48 hours post-launch before considering it stable.

“The projects that go wrong aren't the ones with hard problems. They're the ones where nobody was honest about what each week was supposed to produce.”

What this means for you as a client

Every week has a clear output you can evaluate. If you see a demo every week and you're happy with it, the final product won't surprise you. If something's not right, we catch it early when it's cheap to fix. That's why our projects don't run over budget. Not because we're perfect — because we've built a process that surfaces problems before they become expensive.