Writing · Process
How Long Does It Take to Build a Website? A Realistic Timeline
Honest timelines for web design projects — from single-page sites to full platforms — and what actually drives the schedule.
· Michael Nash
The Mark — a marketing or brochure site — is up to two weeks from brief to live. The Site, with a CMS and client-managed content, is up to three weeks. The Platform — booking flows, payments, customer accounts — is up to four weeks, with scope agreed on a call first.
These timelines start from the day design work begins, not from the day you first make contact. The gap between inquiry and kickoff is usually 1–2 weeks depending on schedule.
What the Timeline Actually Includes
A website project has four stages that run roughly sequentially:
- Discovery — Understanding the business, the audience, and the goal. 1–2 days.
- Design — Building layout, typography, and component library. 3–7 days depending on scope.
- Development — Writing the code, wiring the CMS, building forms. 3–10 days depending on scope.
- Review and launch — Client review, revisions, DNS cutover. 2–4 days.
The biggest variable is client availability. Projects that hit 3-week timelines are almost always waiting on content, feedback, or a decision at some stage.
What Discovery Actually Involves
The one-line description — "understanding the business" — undersells what happens in Discovery. This is the stage that determines whether the rest of the project moves efficiently or spends weeks correcting assumptions.
At kickoff, we need to understand several things clearly: What does the business actually do, and for whom? What's the one thing a visitor should do when they arrive on the site — book a call, make an enquiry, buy a product, get in touch? Who are the competitors, and what do their sites do well or badly? Are there existing brand assets (logos, fonts, colours) or are we building from scratch? What content exists already, and what needs to be written?
The answers to these questions drive every subsequent decision. The headline on the homepage comes from the answer to "what should a visitor understand immediately." The navigation structure comes from "what are the most important pages for the audience to reach." The CTA design comes from "what's the one thing we want people to do."
Discovery at Atlas is not a questionnaire sent and forgotten. It's a structured conversation — usually a single focused call or a short series of async exchanges — where we reach genuine clarity on scope before design begins. The output is a brief document: what the site will do, what it won't, and what we need from the client to begin.
Projects that skip proper Discovery — or compress it into a five-minute call — reliably take longer. Decisions that weren't made upfront become requests mid-project, and requests mid-project are scope changes.
What the Staging Link Review Looks Like
At the end of the Development stage, clients receive a staging link — a live URL on a preview domain where the site exists exactly as it will look on launch, but isn't yet indexed by search engines or pointing at the real domain.
This is a deliberate part of the process, not a courtesy. It gives clients the ability to review the site in a real browser, on a real device, before anyone else can see it. It's where typographic errors get caught, where a CTA that made sense in the design turns out to need rewording, and where mobile layout issues that weren't visible in a static mockup become clear.
We ask for one consolidated round of feedback from the staging review. "Consolidated" matters: gathering feedback from two people separately and sending it in two rounds doubles the review time and creates conflicts between versions. One document, one set of notes, submitted together.
Clients who complete the staging review quickly — and who consolidate their feedback before sending it — launch faster. Consistent pattern, every project we've run. The staging review is often the last decision-making stage before launch. Treat it as such.
Why Atlas Doesn't Bill Hourly
The studio charges fixed, scope-based prices for every project. There's no hourly rate, no time-tracking, and no invoice that varies based on how long a task took.
This isn't arbitrary — it's a consequence of how good work actually gets done.
Hourly billing creates the wrong incentives on both sides. A studio billing by the hour has no incentive to be efficient — more time means more revenue. A client being billed by the hour has an incentive to approve quickly and avoid scope questions, because every exchange costs money. Neither of these serves the project.
Fixed-price work inverts this. When the price is set, the studio's incentive is to deliver the scope cleanly and efficiently. The client can ask questions, request revisions within scope, and engage fully in the process without watching a meter run.
It also means the client knows what they're paying before they start. There's no "the project ran over because of unexpected complexity" invoice at the end. Scope is agreed in writing. Price follows from scope. The invoice is the same as the quote.
The only adjustment that changes price is a scope change — something added after kickoff. Those are quoted separately, transparently, and accepted or declined by the client before work begins on them.
When Scope Evolves: The MSM Example
Scope changes do happen. The question is how they're handled.
Mobility Scooters Mallorca came to us with an initial brief that looked like a brochure rebuild — a clean, fast site that communicated the service and took enquiries. As the project developed, it became clear the business had more to gain from a structured enquiry platform: customers selecting scooter type, hire dates, quantity, and location step by step, so every enquiry arrived complete rather than as a generic message.
That's a meaningful scope change. The solution wasn't to absorb the additional work into the original price (which would compromise delivery), nor to restart the project from scratch (which would lose the work already done on brief and design). Instead, we paused, re-scoped in writing, agreed the revised price and timeline, and continued.
The result: a platform that launched with page one Google rankings for key Mallorca mobility scooter search terms within weeks, and direct bookings confirmed via Resend from the start.
The point isn't that scope changes are easy. They're not. But they can be handled cleanly if the original brief is documented, both parties agree on what changed and what it costs, and the project restarts with an updated scope document rather than informal verbal agreements about "just adding a few more things."
Mallorca-Based and Remote Clients
The studio is based in Mallorca. Most of our clients are not — they're UK businesses, Northern European businesses, or businesses based elsewhere in Spain. This has shaped how we work.
Projects run asynchronously by default. Written briefs, staging links for review, consolidated feedback in a single document. This isn't a workaround for remote work — it's how structured project management works regardless of geography. We've found that async-by-default produces better-documented projects and cleaner handoffs than meetings-first workflows.
Video calls happen at two points: the initial kickoff conversation (to establish brief and relationship before design begins) and the final pre-launch review (to walk through the staging link together and confirm go/no-go). Everything in between can be handled in writing.
For Mallorca-based clients and anyone in Spain, the timezone alignment makes this easier — we're on the same time. For UK clients, the one-hour difference is effectively invisible. For clients further afield, we accommodate schedules where needed. The async structure means the project doesn't stall because of a three-hour meeting slot that doesn't exist.
The Content Problem
Most project delays are content delays. A studio can design and build a site in two weeks. If the client is still writing copy on week three, launch slips to week five.
We provide a content brief at the start of every project: exactly what we need, in what format, by what date. Clients who prepare content before kickoff consistently launch on time.
Why Fixed Timelines Work Better Than Hourly Projects
Hourly web projects expand to fill available time. When there's no budget ceiling, scope creep fills the gap. Fixed-price, fixed-scope projects create a forcing function — decisions get made, content gets written, and launches happen.
Every project we take on has a scope document agreed in writing before we start. Additional requests are quoted separately. The original timeline doesn't move unless the original scope does.
Stage-by-Stage: What to Expect
Week 1
We design the key pages and share them for feedback. You'll see the homepage, a secondary page, and the mobile layout. Feedback comes back in one round.
Week 2
We build the site from the approved designs. CMS is configured, forms are wired, content is imported. You receive a staging link to review.
Week 3 (if needed)
A second round of revisions if required. DNS cutover to your domain. Launch.
For The Mark, weeks 1 and 2 often compress into one. See the full services breakdown for what's included in each tier.
Frequently Asked Questions
What slows a project down?
Content not ready at kickoff, stakeholder rounds that require multiple sign-offs, and scope changes mid-project. The first is the most common. We've had projects slip by three weeks because a logo was still in revision at a third party. We've had projects that launched in ten days because everything was ready on day one. Preparation before kickoff is the single biggest factor.
Can you build faster if we need it?
Sometimes. The Mark can launch in under a week if content is ready and the brief is clear. The Site rarely compresses below two weeks — quality design takes time.
What do I need to have ready before we start?
Your business name, domain (or decision on one), a brief description of what the site needs to do, and any content you already have (copy, photos, logos). We'll help fill the gaps.
How do revisions work?
Each tier includes one consolidated round of revisions at the design stage and one at the development stage. Additional revision rounds beyond the included allowance are quoted separately. Revisions are changes within scope — not scope additions. If you want to add a page that wasn't in the original brief, that's a scope addition and it's quoted as one.