Insight · 7 Min Read · 842 Words
The Three-Week Website: The Process, The Trade-Offs, What You Need To Bring
A realistic guide to how a three-week small-business website build works, what is included, what slows it down, and what the owner needs to supply.
Published 2026-05-03 · Updated 2026-05-03
Three Weeks Is A System, Not A Rush Job
A three-week website sounds fast because many UK agency timelines are much longer. The pricing research records small-agency projects around 4–10 weeks and broader web-design ranges that can stretch further depending on scope [`e2-bark-price-guide-uk-2025`]. A shorter timeline is possible for local-business websites only when the scope is controlled and the owner is ready to make decisions.
The point is not to cram an agency project into fewer days. The point is to choose the right shape. A single-page site for a clear offer does not need a six-month discovery phase. A business with teams, policies, proof, and reassurance needs more structure. A business targeting many services or places needs a content system. Those are different products, which is why our packages split into P1, P2, and P3.
Three weeks also does not mean three weeks of silence followed by a reveal. It means a tight rhythm: brief, build, live. Each week has a job. Each job has owner inputs. If the inputs arrive late, the timeline moves. That honesty protects both sides.
Week 1: Brief
Week 1 is where most projects are won or lost. We need the business type, town, services, proof, opening hours, pricing posture, booking route, tone, existing assets, and what success should look like six months after launch. We also need to know what is out of scope. A clean no is often more useful than a vague maybe.
The output of Week 1 is not a giant strategy deck. It is a sitemap, content list, page priorities, visual direction, first copy outline, and a decision on package fit. For a P1 build, that might be one high-density page. For P2, it might be home, about, services, gallery, FAQ, contact, and legal. For P3, it might include service and area templates that can scale without writing every page by hand.
What you need to bring: one focused conversation, real words where you have them, photos or a photo plan, service names, prices if public, best proof, address or service area, and a named person who can approve decisions. Without that, speed becomes guesswork.
Week 2: Build
Week 2 turns the brief into the site. We build the visual system, page sections, responsive layouts, contact routes, metadata, schema, images, and the first proper copy pass. This is where the defaults matter: accessibility, privacy, forms, structured data, sitemap, and hand-over notes are not separate extras bolted on at the end.
There are trade-offs. A three-week build is not the moment for a custom booking engine, large e-commerce catalogue, private portal, or brand identity exploration from nothing. Those can be separate scopes. The build works because we use a repeatable technical base and spend the bespoke effort on the business details visitors actually see.
The owner job in Week 2 is feedback. Not committee feedback across ten people, and not silence. We need clear comments on factual accuracy, services, photos, and tone. Design feedback is welcome, but it needs to connect to the business goal. 'Make it pop' is not a direction. 'The booking button needs to be more obvious on mobile' is useful.
Week 3: Live
Week 3 is for launch quality. We check forms, mobile layout, focus states, reduced motion, image weight, metadata, JSON-LD, sitemap, robots, cookie consent, legal pages, and basic analytics. We make sure the contact email is correct, phone links work, and the site has a clear route for the owner to receive enquiries.
We also hand over. That means source files, hosting notes, domain route, and a walk-through. The ownership rule matters because it keeps the relationship clean. If you stay on a Care plan, it is because the support is useful, not because the website is trapped.
What can delay launch? Missing photos, unapproved copy, domain access, unclear offers, late legal wording, or a new scope request that belongs in phase two. None of these are failures. They are normal project realities. The fix is to name them early and decide whether launch waits or the item moves to the backlog.
What You Get At The End
At the end of a good three-week build, you do not just get a prettier homepage. You get a site that explains the business, answers buyer questions, routes enquiries, carries structured data, has a privacy and accessibility baseline, can be measured, and belongs to you. That is the product.
You also get a clearer backlog. Not everything belongs in launch week. A photoshoot, a booking integration, a second location, or a deeper service-area layer can wait until the first version proves what visitors need. Naming phase two early keeps phase one calm and protects the launch date.
The sensible next step after launch is not constant redesign. It is observation. Which page gets attention? Which questions still arrive by phone? Which service needs its own page? Which photos need replacing? A website earns its keep when it keeps becoming more accurate. The three-week build is the start of that system, not the end of the business's digital work.