The Web Development Process: What Actually Happens, and What You Have to Do

Most explanations of the web development process describe what the agency does. That’s the easy half. The harder half, and the one that decides whether your project lands on time, is what you have to do while it’s happening.

Industry data puts it plainly: around 65% of redesign projects exceed their original timeline, and content delays are the primary cause in roughly 60% of those cases. Separately, about 78% of software projects experience scope creep. Neither of those is an agency execution problem. Both sit on the client side of the table.

So here’s the process as it actually runs, with your obligations marked at each stage. We build sites this way at Tequila, and the projects that finish on schedule are almost always the ones where the client knew what was coming.

Stage 1: Requirements and structure

Before anything visual exists, the site’s purpose, audience, page inventory, and information architecture get defined. This produces a sitemap and a set of page templates rather than a design.

Your job: name a single decision-maker. Not a committee. Every additional approver adds coordination time on top of review time, and a homepage that one person can sign off in a day can take a committee two weeks. If your organisation genuinely needs multiple sign-offs, say so now so the schedule accounts for it.

Stage 2: Wireframes

Low-fidelity layouts first, showing content order and hierarchy without styling. Then high-fidelity wireframes that get closer to the real thing.

This stage exists to have arguments cheaply. Moving a section in a wireframe costs minutes. Moving it after the build costs days.

Your job: review for structure, not aesthetics. If you find yourself commenting on colours at wireframe stage, the conversation has gone off track. The question to answer is whether the order of information matches how your customers actually decide.

Stage 3: Visual design

Full design of key templates, applying brand identity, typography, imagery, and interaction behaviour. Usually the homepage and two or three representative inner pages rather than every page.

Your job: consolidate feedback into a single response per round. Agencies typically allow five to seven business days for design review. When responses take two to three weeks, the whole schedule slides by that amount. Fragmented feedback arriving across a fortnight from four people is worse than one slower reply that has already been reconciled internally.

Stage 4: Content production

This is where projects die, and it’s worth being blunt about why.

Content that has to be written, photographed, or produced during the project takes three to eight weeks depending on volume and approval complexity. Most clients budget zero weeks for it because writing copy feels like something that can happen alongside everything else. It cannot. Development cannot finish a page that has no final copy in it.

Your job: start content before the project kicks off, not when a developer asks. If you’re supplying copy, have a first draft of every page before design begins. If we’re writing it, get us the source material and interview time in the first fortnight.

A practical rule: whatever launch date you have in mind, set it after the content inventory is complete rather than before. A date chosen before anyone has counted the pages is a guess.

Stage 5: Build

Designs get converted into working templates. On a WordPress project this means building a component system and CMS fields so your team can edit pages later without breaking layouts, rather than hard-coding each page.

This is also where performance is won or lost. Page weight budgets, image formats, script loading, and caching all get decided here, and the choices are much harder to reverse afterwards.

Your job: mostly stay out of the way, with one exception. If you’re going to request new functionality, request it now. A client portal added at build stage is a costed change. The same request at testing stage is a restructure.

Stage 6: Content population and integrations

Real content goes into the CMS. Forms, CRM connections, payment gateways, booking tools, analytics, and consent management get wired up and tested individually.

Your job: provide access credentials early. Waiting on a login to a payment gateway or CRM is one of the more avoidable delays, and it happens constantly.

Stage 7: Testing

Functional testing, cross-browser and cross-device testing, performance testing, accessibility checks, and security review.

Device coverage matters more here than most clients expect. In the UAE, mobile phones account for roughly 75.3% of web traffic and 96% of internet users access the web via mobile, with Android holding about 81% of the device market against iOS at 18.8%. A site signed off on an iPhone has been signed off on a device representing under a fifth of your audience.

Your job: run user acceptance testing properly. Budget five to ten hours. Click every form, submit every enquiry, check every phone number. You know your business processes better than anyone building the site.

Stage 8: Pre-launch SEO, and the thing most projects skip

If your URLs are changing, every old URL needs a mapped 301 redirect to its closest equivalent before launch. Not after. Not “we’ll catch the 404s in Search Console.”

Traffic losses of around 40% are documented after structural changes go live without redirect mapping. That’s not a slow decline you can recover from casually. That’s your organic pipeline disappearing in a week.

The full pre-launch list:

• 301 redirect map covering every existing indexed URL
• Title tags and meta descriptions migrated or rewritten, not left as CMS defaults
• Canonical tags checked on every template
• Staging environment’s search-engine block removed
• XML sitemap regenerated and submitted
• Analytics and conversion tracking verified as firing, including phone and WhatsApp clicks
• Structured data validated
• SSL and forced HTTPS confirmed

Your job: insist on seeing the redirect map before launch day. If your agency can’t produce one, that’s the answer to whether they’ve done this before.

Stage 9: Launch and the first month

Domain pointed, files deployed, DNS propagated. Then thirty to sixty days of monitoring: watching Search Console for crawl errors, checking that rankings hold, and comparing conversion against the old site.

Your job: don’t treat launch as the finish line. The first month is when real-world traffic surfaces things testing didn’t.

Stage 10: Maintenance

Core, theme, and plugin updates, security monitoring, backups, and performance checks. Ongoing maintenance is not an upsell on a WordPress site. An unpatched WordPress install is a security incident waiting for a date.

Realistic timelines

Project size	Typical duration	Client time required
5–15 pages, single decision-maker, content ready	6–10 weeks	40–70 hours
15–30 pages, multiple stakeholders	12–20 weeks	75–150 hours
30+ pages, custom functionality, integrations	16–24 weeks	150+ hours
Enterprise with compliance or migration	4–12 months	Dedicated internal resource

That client time column is the one people miss. It’s spread across three to five people and covers weekly calls, three to five design feedback rounds, development reviews, UAT, and training. It’s real work, and it needs to be in someone’s calendar.

One local note: plan around Ramadan, Eid, and the summer exodus. A project starting in May with a September launch is going to hit a period where half the approvers are out of the country.

What to ask before signing

• Who is my day-to-day contact, and what’s the response time commitment both ways?
• How many design revision rounds are included, and what happens after that?
• Who is writing the content, and by when does it need to be final?
• Will I get a redirect map before launch?
• What happens in the first thirty days after launch, and is it included?
• What does maintenance cover, and what falls outside it?

Frequently asked questions

Planning a build and want an honest read on the timeline before you commit to a launch date? Talk to us. We’ll tell you what your content situation actually implies.