How Long Does It Take to Build a Website?
A small business site takes 4–6 weeks from kickoff, e-commerce 8–12. Why projects run late, and four things that keep yours on schedule.
Founder & lead developer at WebDevStudio — React, TypeScript and MERN
From kickoff, a small business marketing site typically takes 4–6 weeks. E-commerce and integration-heavy builds run 8–12 weeks, and custom applications 3–6 months. The most common cause of overrun isn't development — it's waiting on the client's content, feedback and approvals. A timeline that doesn't name your obligations as well as the developer's will be missed.
"From kickoff" is doing real work in that sentence. Kickoff is the day the developer has what they need to start, which is often weeks after the day you signed. If you're still choosing who to hire, how to hire a web developer when you don't know how to code comes first.
Been quoted a timeline you're unsure about? Tell me the scope and what you already have ready, and I'll tell you whether it's realistic — free, before you commit. If the timeline is fine, I'll say so. Get in touch.
Typical timelines by project type
| Project | From kickoff | What usually sets the pace |
|---|---|---|
| Landing page / one-pager | 1–2 weeks | How fast the copy is ready |
| Small business site, 5–8 pages | 4–6 weeks | Content for every page, plus two review rounds |
| Larger marketing site, 10–15 pages | 6–10 weeks | Content volume and the number of approvers |
| E-commerce | 8–12 weeks | Product data, images, payment and shipping setup |
| Integration-heavy build | 8–12 weeks | The other system's API, and access to a test account |
| Custom web application | 3–6 months | User roles, permissions and the number of workflows |
These are working ranges for a competent solo developer or small studio, and they assume you're responsive. They stretch when approvals involve a committee, and they compress only slightly when you throw money at them — most web work doesn't parallelise as neatly as people hope.
What actually happens in each phase
- Discovery and scope (3–7 days). Turning what you want into something specific enough to build and price. Skipping this is how projects end up in change requests.
- Design (1–2 weeks). Layouts and a visual direction, then a review round. Longer if it's a fully custom design rather than a design system applied to your brand.
- Build (2–4 weeks for a marketing site). The part people imagine is the whole project. It's usually less than half of it.
- Content population. Almost always the bottleneck — see below.
- Testing and fixes (3–5 days). Browsers, devices, forms, and the things that only break with real content in them.
- Launch and handover (1–3 days). DNS, redirects from the old URLs, analytics, and a walkthrough so you can run it.
Note how much of that list isn't coding. When a quote's timeline looks short, the usual explanation is that it counted only the build phase — which is why timeline belongs in the quote as a line item with your obligations attached, per what should be in a web development quote.
Why projects run late — and why it's usually not the developer
This isn't a complaint about clients. It's a structural feature of web projects, and knowing it in advance is the thing that prevents it.
Content is the number one cause. Writing twelve pages of copy about your own business is genuinely hard, it's nobody's actual job, and it always takes longer than the week everyone assumed. Meanwhile the build is finished and waiting, which is why a project can be "almost done" for a month.
Feedback rounds are the second. A review that sits for ten days doesn't cost ten days — it often costs more, because the developer has moved to another project and has to pick yours back up.
Approvals are the third. One decision-maker is fast. Three people who must agree, one of whom is on leave, is a fortnight nobody scheduled.
What you have to supply, and by when
| What | When it's needed | Cost of being late |
|---|---|---|
| Final copy for every page | Before build starts, ideally | The single biggest source of delay |
| Logo files, fonts, brand colours | Before design starts | Design work gets redone |
| Photos, or a decision to buy stock | Before content population | Pages sit half-finished |
| Domain and hosting access | Before launch week | Launch slips regardless of readiness |
| Consolidated feedback per round | Within 2–3 business days | Compounds — the developer context-switches away |
| A named decision-maker | Day one | Every round takes as long as the slowest approver |
The full pre-kickoff list is in what to give a web developer before starting.
Two timeline red flags
A timeline that doesn't name your obligations. If the schedule lists only the developer's milestones, it will be missed, and the conversation about whose fault that was will be unpleasant. A schedule with your deadlines in it is a sign of someone who has run projects rather than just sold them.
"Two weeks" for a custom build. Either it's a template being sold as custom, or discovery, testing and handover have been quietly left out of the count. Ask what happens in each week — the answer resolves it immediately.
How to keep the project on schedule
- Write the content before the build starts, not during it. If you can't, say so up front so the schedule reflects reality instead of hope — and consider paying for copywriting, which is cheaper than a two-month stall.
- Name one decision-maker with authority to approve. Gather other people's opinions before the round, not during it.
- Consolidate feedback into one document per round. Ten separate emails over a week is a week, not ten minutes.
- Book the review slots in advance, in your calendar, at kickoff. The rounds you scheduled are the ones that happen on time.
When you don't need to hire anyone
If your honest answer to "when will the content be ready?" is "I have no idea", then the fastest route to a live site may not be hiring a developer at all — it may be a site builder you fill in yourself over a few evenings. A developer can't move faster than your content, and paying someone to wait is the most expensive way to be slow.
What I'd recommend
Add two weeks to whatever timeline you're given, and spend them on content before the project starts rather than during it. Projects that begin with the copy written finish roughly on schedule; projects that begin with "we'll sort the content as we go" do not.
And treat any timeline that doesn't ask anything of you as a warning rather than a convenience.
Frequently asked questions
How long does it take to build a small business website?
Typically 4–6 weeks from kickoff for a 5–8 page site, assuming the content is ready and feedback comes back within a few days. Larger 10–15 page marketing sites run 6–10 weeks, e-commerce and integration-heavy builds 8–12 weeks, and custom applications 3–6 months. Kickoff means the day the developer has what they need — often weeks after you signed.
Why do website projects take longer than quoted?
Almost always because of content, feedback and approvals rather than development. Writing pages of copy about your own business is harder than it sounds and is nobody's actual job, so the build finishes and waits. Slow review rounds compound the delay, because the developer context-switches to other work and has to pick yours back up.
Is two weeks realistic for a custom website?
Rarely. Two weeks usually means either a purchased template being presented as custom work, or a count that excludes discovery, testing, launch and handover. Ask what happens in each week — a developer who has actually run projects will walk you through discovery, design, build, content, testing and launch without hesitating.
What makes a website project finish on time?
Content written before the build starts, one named decision-maker with authority to approve, feedback consolidated into a single document per round, and review slots booked into calendars at kickoff. Those four things matter more than any scheduling technique the developer uses, because they remove the bottleneck that causes most overruns.
Can I speed up a website build by paying more?
Only slightly, and less than people expect. Web projects don't parallelise cleanly — adding people to design and build creates coordination work, and none of it removes the real constraint, which is usually your content and approvals. Paying for copywriting genuinely does speed things up, because it attacks the actual bottleneck.
Where to start
Before you agree a date, answer one question honestly: when will the final copy for every page exist? That date, not the developer's capacity, is what sets your launch.
If you'd like a realistic timeline for your scope, describe it and I'll give you one — including the parts that depend on you. Get in touch, or see what I build.
Interested in working together on a React or MERN project?
Get in Touch