The build phase — what happens while nothing shows

The build phase is where an approved, signed-off design becomes a working website — markup, styling and functionality written against a private development environment, rather than a static image of what the site will look like. It is the stage clients most often describe as “going quiet,” and understanding what is actually happening during it is the fastest way to tell normal progress from a stalled project.

What actually happens during the build phase of a website development project

What happens during build	Why it is not visible day to day
Turning the approved design into markup and styles	Built on a development environment, not the live domain
Setting up the platform (WordPress, Shopify, a custom system)	Configuration work with no visual output of its own
Building any functionality — forms, booking, ecommerce	Often tested internally before it is shown, to avoid presenting broken features
Making the site responsive across device sizes	A single design has to be translated into several working layouts
Connecting third-party systems (payments, booking calendars, CRM)	Integration work that produces no visible change until it is complete

None of this produces something that looks meaningfully different day to day the way a design concept did, which is precisely why this stage is the one clients most often describe as feeling stalled, even on a project that is running exactly on schedule.

Why build happens away from the live site

Building directly on a domain the public can already see risks showing visitors a half-finished, broken or embarrassing version of the site while it is still being worked on. Development happens instead on a private, unpublished environment — sometimes called a staging site — that only the supplier and, usually on request, the client can access. This is standard practice, not a sign of anything being hidden; the alternative would expose unfinished work to search engines and to anyone who happened to visit during the build.

What a client should reasonably expect to see

A build that is genuinely progressing should still be showable, even mid-stream. Reasonable things to ask for include: a staging link to view work in progress, even incomplete; a brief check-in at agreed intervals, rather than silence until the whole thing is done; and early visibility of any custom functionality specifically, such as a booking form or product catalogue, because functional problems are cheaper to fix the earlier they are found. A supplier who cannot produce any of this on request, partway through a multi-week build, is worth a direct conversation — not necessarily evidence of a problem, but a fair thing to ask about.

What determines how long the build stage of a project takes

Build duration is driven by the same factors scoped earlier in the discovery phase of the project: the number of unique page templates, how much custom functionality is involved versus off-the-shelf platform features, and how much of the site can be assembled from existing, tested components versus built from nothing. A site built on an established platform such as WordPress or Shopify, using well-supported existing functionality, is typically faster to build than a fully custom system doing the same job — because much of the underlying engineering has already been solved and tested by the platform itself, rather than being written fresh for this project.

What can still change during build, and what cannot

Visual design should already be settled at this point — the wireframes and design concepts belong to the earlier discovery and design stage, not this one — see design sign-off for why a change to the approved design during build is treated as new work rather than a routine adjustment. What is normal to discover and adjust during build is technical detail that could not have been fully anticipated earlier: how a particular piece of content behaves in the actual layout, whether a third-party service integrates as smoothly as expected, or a browser-specific quirk that only appears once real code is running. These are ordinary build issues, not scope changes, and a competent supplier resolves them without treating every one as a billable extra.

Where responsibility sits during this stage

Build is almost entirely supplier-led work. The client’s main responsibility during this window is to keep supplying anything still outstanding from earlier stages — content that has not yet arrived, decisions still pending, access to any third-party systems the site needs to connect to — because a build waiting on any of these cannot proceed on the rest of the site regardless of how quickly the supplier is working. General information on what a development engagement typically includes at this stage is on web development services.

Version control and why a supplier’s process here matters

A build conducted with proper version control — a system that records every change made to the code, by whom and when — can be rolled back to a working state if something goes wrong partway through. A build conducted without it relies entirely on the developer’s memory and manual backups, which is riskier on any project beyond the smallest brochure site. It is a reasonable, specific question to ask a supplier: is this project under version control, and could a mistake made this week be undone without starting the affected part again from nothing. A supplier who has never had to answer this question before is not necessarily incompetent, but the answer tells you something real about how the build is actually being run.

Platform lock-in decisions made during build

Some of the choices made during build are quietly hard to reverse later, and it is worth knowing which ones those are before the stage is finished rather than discovering it during a future redesign. Custom functionality built specifically for one platform — a booking system wired directly into WordPress, for instance — typically has to be rebuilt, not migrated, if the business ever moves to a different platform. Content stored in a genuinely portable format, by contrast, can usually be exported and reused regardless of what the site is rebuilt on next. Asking, during build rather than after it, what would need to be rebuilt from scratch if the platform ever changed is a fair question with a concrete answer, and the answer affects how much independence the finished site actually gives the business.

What comes next in the process, before launch

Once the underlying site is built, the approved content gathered earlier in the project is loaded into it. See content population for what that stage involves and why it is treated separately from the build work itself.