From brief to deploy: how a web project gets built right

"I paid a deposit three months ago and I have no idea where the site stands." We hear that sentence a lot from people who come to us after a project went wrong. The problem is almost never the technical skill of whoever built it: it's the process. A project without clear phases, without checkpoints and without a defined point of contact goes off the rails even with the best developers.

That's why it's worth explaining what actually happens between the first meeting and the moment the site goes live. Not to reveal some trade secret, but because a client who knows what to expect works better, decides faster and spends less. Our process has four phases: brief, design, build, deploy. Let's walk through them, including what you get to see in each one.

Phase 1: the brief (where projects are won or lost)

Most projects that fail, fail here, before a single line of code. A bad brief produces a wrong estimate, misaligned expectations and a result that "technically works" but serves no purpose.

In the brief we don't ask "what kind of site do you want". We ask what needs to happen because of the site: more quote requests? Bookings? Online sales? Fewer phone calls about the same repeated questions? From there we work backwards: who the visitors are, where they come from, what they need to find within ten seconds, what action they should take.

This is also where we put the uncomfortable questions on the table:

• Content: who writes the copy? Who provides photos and materials? It's the number one cause of delays, so it gets decided up front.
• Real constraints: is there a hard deadline (a trade show, a launch) or a rough one? Is there an existing management system the site needs to talk to?
• What you DON'T need yet: cutting what can wait is the most honest way to fit the budget to the goals.

What you see at the end of this phase: a short, readable document describing goals, pages, features and responsibilities (who does what, by when), together with the quote. If anything changes later, we go back to that document: it's the anchor of the whole project.

Phase 2: design (decide by looking, not by imagining)

The most expensive way to find out you don't like a choice is to see it already developed. That's why design comes before code: a visual, navigable version of the key pages, discussed while changing your mind is still cheap.

This isn't just about aesthetics. It's about hierarchy: what a visitor sees first, where the eye lands, how many steps it takes to reach the contact form or the checkout. A site can be beautiful and still not convert, because it demands too much effort from the visitor to figure out what to do.

Two things we've learned to demand from ourselves at this stage:

• Design for the phone first. In most industries more than half of visits come from mobile. A design born on a big screen and then "adapted" shows, and it shows in the results.
• Design with real content, or at least realistic content. A layout filled with dummy text always looks perfect; the problems only surface with the real copy.

What you see: the screens of the main pages, to approve or correct. Revision rounds are planned and bounded: they exist to converge, not to start over every time.

Phase 3: the build (the invisible part that makes the difference)

With the design approved, development starts. Paradoxically, this is the phase with the fewest decisions to make together: the important choices have already been made, and that's exactly the sign that the first two phases did their job.

What happens here, though, determines the life of the site over the next three to five years. A site built with care is born fast (performance isn't "added" later: it's built in), born secure (updates, protected forms, proper data handling) and born readable by Google, with the technical structure that makes it findable.

During the build the project lives on a preview environment: a private address where the site grows week after week. No "I disappear for two months and then surprise you": you can check progress whenever you want, and corrections happen while building, not all at the end.

What you see: the preview link, updates at an agreed cadence and a single person to write to. If something comes up that wasn't in the brief, it doesn't sneak into the project quietly: we talk about it, assess the impact on time and cost, and decide together.

Phase 4: deploy (going live is a process, not a click)

Launch day shouldn't be exciting. If it is, something went wrong earlier. Before the site goes live we run through a checklist: forms working end to end (with notifications that actually arrive), speed measured on real connections, behaviour across devices, redirects from the old pages if a previous site existed, so the ranking you've built up isn't lost.

And then the question too many people ask only after the fact: what happens next? A live site is a living system: security updates, backups, small changes, fresh content. We define from the start how all of that is handled, because the value of a site is measured in years, not at handover.

What you see: the site live, the access that belongs to you (the domain is yours, the content is yours), a short guide for day-to-day use and a clear agreement on support and maintenance.

How to recognise a serious process

This is the story of how we work, but the substance is universal. If you're evaluating a partner, whoever they are, some questions reveal a lot:

• "How does your process work?" If the answer is vague, so will be the project.
• "What do I see, and when?" A serious partner has planned checkpoints, not "we'll talk when it's ready".
• "Who writes the content?" If nobody raises the topic, the delay is already scheduled.
• "What happens after delivery?" If the answer is silence, silence is what you'll get after delivery.

A lower quote with a confused process almost always ends up costing more than an honest quote with a solid one: you pay in delays, rework and missed opportunities.

If you have a project in mind and want to see how we'd approach it, tell us about it: the quote is free and the initial brief commits you to nothing. Worst case, you leave the meeting with clearer ideas.