Most of the risk in a web project is not technical. It is a decision nobody made, a page nobody wrote, or a stakeholder who sees the design three weeks after approving it. This process surfaces those things while they are still cheap to fix. Every project runs the same five stages; only the durations change. For costs, see pricing.
Stage 1: Discovery and scoping
We start with what the site has to do — sell, generate enquiries, publish, serve logged-in users. Then we audit what exists: analytics, your top pages by traffic, your URL structure, hosting, CMS and every integration in play.
The outputs that matter most are the sitemap and the page briefs — a short brief per page or template saying what it is for, who reads it, what it must contain, what the primary action is. You also get a technical approach, a scope document listing what is in and explicitly out, a quote, and a schedule carrying your dates as well as ours. One to three weeks, longer for e-commerce.
What goes wrong here
Scope stated as adjectives. "Modern", "clean", "like our competitor but better" cannot be built or priced. The other failure is an integration found late — a legacy inventory system, a single sign-on requirement.
Stage 2: Design and content
Wireframes come first, for key templates only: home, a service page, a listing, a detail page, contact or checkout. Then a design system — type scale, colour, spacing, buttons, form and error states — and full comps of those templates at desktop and mobile widths. We design templates, not every page. See design and UX.
Content runs in parallel, and clients underestimate it: real copy and images change layouts, so we design against your actual content. Your proposal states how many revision rounds are included; two per design deliverable is the usual figure. Send one consolidated list from one person. You finish with wireframes, a design system, approved designs and a content plan. Two to five weeks.
What goes wrong here
Content, almost always. A design cannot be signed off against placeholder text, and a build cannot finish without pages. Second: a senior stakeholder who missed discovery reopening the structure at round two. Put them in front of the wireframes.
Stage 3: Build
Front-end templates, back end, CMS modelling and integrations. From day one the work lives on a staging environment — a private, password-protected copy of the site on a real server you can open whenever you want.
We build in template order, so shared components land first. CMS work means modelling content types and fields so your team can edit pages without breaking layouts — most of the value in a WordPress, headless or Contentful build. A store adds product data and variants, tax and shipping rules, and payment integrations. Content loading happens here too, and we train your team on the CMS now, not after launch. You finish with a complete site on staging, full of real content. Four to twelve weeks.
What goes wrong here
Third-party dependencies you do not control: a sandbox API that behaves differently from production, a payment account that takes two weeks to verify, a font licence nobody bought. Start those applications early.
Stage 4: QA and launch
We test, then you test. Our pass covers:
- Every template, form and flow, including the states people forget: the 404 page, an empty search, a checkout with a declined card.
- Browsers and devices — current Chrome, Safari, Firefox and Edge on Windows and macOS, plus iOS Safari and Android Chrome on real handsets and a tablet.
- Core Web Vitals: LCP, INP and CLS measured on staging and again after launch, tuning image formats, font loading, script deferral and caching until they hold on a mid-range phone.
- Accessibility against WCAG 2.1 AA — contrast, visible focus, heading order, form labels, alt text, keyboard operability. Tooling finds some of it; manual keyboard and screen reader passes find the rest.
- Redirect mapping when you are replacing an existing site. We export every live URL from a crawl, analytics and Search Console, map each to a new destination, and load the 301s before the DNS change. Unmapped URLs are how redesigns lose search traffic.
- Housekeeping: analytics and tag verification, sitemap, robots.txt with the staging block removed, SSL, backups, and a form delivery test to a real inbox.
Your team then gets an acceptance window on staging, working from one shared issue list. Launch is a DNS and hosting cutover at an agreed time, then a check of the live site and redirects. Budget one to two weeks plus launch day.
What goes wrong here
DNS and email. Moving a domain can break mail if MX records are not carried across; we check first, but need registrar access. The other is a stakeholder who first tests in launch week and raises something structural.
Stage 5: Support after launch
Launch is followed by a defect window: a defined period in which anything not working as specified is fixed at no charge. Its length is set in your contract; thirty days is what we normally scope. It covers defects in what we built, not new work.
After that, ongoing work is either ad hoc or a standing arrangement — CMS core, plugin and dependency updates, security patching, backups with restore testing, uptime monitoring, agreed hours a month. That sits under maintenance and support.
What goes wrong here
Nobody owns the site. A WordPress or WooCommerce install left eight months without updates is a security problem, not just a stale one. Decide before launch whose job updates are.
What we need from you
- Content — copy, images, product data and brand assets by the dates in the schedule. If you want us to write or source it, that is quoted in stage 1, not assumed.
- Feedback on time, consolidated, in writing, to a turnaround agreed up front.
- One decision-maker who can approve a design and close an argument. Committees advise; one person signs off.
- Access to the domain registrar, DNS, hosting, CMS, analytics, payment gateway and third-party services.
Being blunt: the most common cause of a slipped launch date is not development, it is waiting — for copy, for a decision, for a login. The schedule carries your dates too, and we flag slippage when it happens rather than at the end.
How change requests work
A change request is anything outside the scope document agreed in stage 1: a new template, a new integration, an extra language, a redesign of a signed-off template, a different CMS. Fixing something that does not match the spec is a bug, and we fix it at our cost.
The mechanics are deliberately dull. You describe what you want in writing, we come back with the price and the schedule impact, and you approve in writing before anything is built. Nothing gets added on a verbal "sure, throw it in". Timing matters more than size: moving a navigation item during design is a redraw, while the same change after build is template work, retesting and possibly new redirects.
What you own at the end
- The code, in a repository you control, with build configuration and deployment instructions.
- The content and designs produced for the project.
- The domain, registered to your company in your own registrar account. If we register it during the project, it transfers to you.
- Hosting, CDN, analytics, email and payment accounts in your name, with you as owner and us as a collaborator you can remove.
- Documentation: how to edit content, where the site deploys, what integrations exist and what credentials they need.
We do not hold client sites on our own accounts. If you go elsewhere you take everything with you and the next developer can pick it up — a fair question to put to any agency; more in our FAQ. Three anonymised projects are written up in our case studies; those figures are self-reported by the clients, not independently verified.
Still deciding? Start with the services overview. When you are ready, email [email protected] with what you want built and roughly when you need it live — we reply within one business day. See the contact page.