Content that does not exist yet
The single largest cause, by a distance. Nobody scheduled writing the words, so nobody wrote them, and the site sits finished except for the bit that matters.
Guide
How long does it take to build a website?
The honest answer depends far less on the building than most people expect. Here is where the weeks actually go, and what decides whether yours takes one month or six.
A website takes as long as the slowest of three things: the decisions, the content, and the build. In most small business projects the build is the fastest of the three, which surprises almost everybody.
A simple brochure site with content ready and one decision maker can be live in weeks. The same site, with content that nobody has written and approvals routed through four people, takes months, and the extra time is not spent building anything.
We will not quote you a fixed number of weeks on a public page, for the same reason we do not publish figures: it would be a guess about a project we have not scoped. What we can do is show you exactly which stage eats the calendar, so you can look at any schedule you are given and see whether it is realistic.
Where the time actually goes
-
Working out what the site is for
Short, and skipping it is expensive. What should the site cause to happen: calls, bookings, enquiries, applications? Which pages exist and why? Get this wrong and you rebuild sections later, which costs far more calendar time than the conversation would have.
-
Content: the stage that decides everything
Every word and every photograph. This is where projects live or die. If content is being supplied by you, this stage runs at the speed of your evenings, and no amount of chasing changes that. If it is being written for you, it moves, but it still needs your input and your approval. Either way it is the long pole, and pretending otherwise is how schedules slip.
-
Design
Laying out how the site looks and behaves. A template shortens this considerably. Custom takes longer and is worth it when credibility is the thing you are selling. The delay risk here is not the designing. It is revision rounds with no agreed limit and no single decision maker.
-
The build itself
Turning the design into a real site: structure, pages, forms, mobile behaviour, speed. Usually the most predictable stage, because it is the one with the fewest unknowns. This is why "how long does it take to build" is slightly the wrong question.
-
Integrations, if any
Booking calendars, mailing lists, CRMs, menu systems, anything the site has to talk to. Each one is its own small project with its own surprises, and they are the most common source of a stage that was scheduled as two days and ran to two weeks.
-
Review and testing
Real devices, real phones, real forms, actually submitted. Content proofread by someone who did not write it. This stage is compressed first when things are late, and that is exactly when it is needed most.
-
Launch
Not a button. DNS, certificates, redirects from old URLs, analytics verified, link preview checked. Book time for it and never do it before a weekend.
-
The weeks after
Search engines need to re-crawl. Real visitors find the things nobody found in testing. A site is not finished at launch, it is only public. Plan attention for the first month.
Why the build is rarely the bottleneck
If you take one thing from this page: the part of a website project you are picturing is not the part that takes the time.
Building pages is skilled, defined work with a known end point. Somebody sits down and does it and it gets done. What does not have a known end point is a decision that has not been made, a photograph that has not been taken, or an approval sitting in a mailbox belonging to someone on holiday.
Look at any stalled website project and you will almost always find it stopped at the same place: a stage that was waiting on the client, on content, or on a decision. Not on a developer. This is not blame, it is just where the time is, and it is useful to know because it tells you what to protect.
The practical consequence: if the schedule matters to you, the lever is not hiring faster builders. It is getting the content sorted and putting one person in charge of saying yes.
What makes a project slower
Approval by committee
Four people with opinions and nobody with authority. Every round of feedback contradicts the last one. The fix is one nominated decision maker, agreed before work starts.
Scope that grows quietly
A booking system mentioned in week three. A shop that "would be good to add". Each is reasonable on its own and each one moves the date, which is fine as long as somebody says so out loud.
Waiting on third parties
A booking provider's support queue, a payment processor's verification, whoever holds the domain not answering. Outside anyone's control and worth identifying early rather than discovering at launch.
Access nobody can find
The domain registrar login from three providers ago. The old host's account. This routinely costs days and it is entirely avoidable by hunting for it in week one, not week six.
Preserving an existing site
On a redesign, the URL audit and redirect map. It is not glamorous and it is the difference between keeping your rankings and starting over on page nowhere.
What actually makes it faster
Not tricks. Three unglamorous things, all of which are on your side of the table.
Have the content, or buy the content
Decide which, in writing, before the project starts. The failure mode is the middle: everybody assumes the other party has it. If you are supplying it, block out real time for it, because "I will do it over the weekend" is the most optimistic sentence in this industry.
One decision maker
One person who can look at a design and say yes. Others can advise. If everyone can veto, nothing ships.
Fast replies
Most questions in a build are small and blocking. A question answered in an hour costs an hour. The same question answered next Tuesday costs a week, because the work reshuffles around it. Nothing else you do will move the date as cheaply as answering quickly.
Get those three right and the project runs at roughly the speed of the actual work. That is as fast as it goes, and it is considerably faster than most projects manage.
Who this is for
- Owners planning a site around a real date: an opening, a season, a campaign
- Anyone whose last website project stalled and who wants to know why
- Businesses weighing a template against a custom build and wondering what the time difference really is
- Anyone who has been given a schedule and wants to know whether it is credible
When this is not the right fit
- Anyone wanting a fixed number of weeks with no scope discussed. That number would be fiction.
- Projects where the deadline is fixed, the content does not exist, and nobody will own writing it. Something has to give, and it is better to say so now.
- Anyone hoping speed can be bought without changing the content or approval situation. It largely cannot.
What SolvenceHQ can help with
We schedule around the parts that actually take the time, and we say up front where we think yours will slow down. A schedule that ignores content is not a schedule, it is a wish.
- Scope the project and give you a realistic stage by stage plan
- Say plainly whether your content is the bottleneck, before we start
- Build the site once the decisions and content are in place
- Redesigns with the URL and redirect work done properly
- Handle launch as its own stage, using our launch checklist
- Stay on afterwards for the first month, when the real feedback arrives
Common questions
What is the single biggest cause of a website taking longer than planned?
Content. Not design, not code, not hosting. The build reaches the point where it needs the actual words and the actual photographs, and those do not exist yet, because writing them was never anybody's scheduled job. The site then sits at ninety percent finished for weeks. If you want a fast project, have the content ready or agree in writing that somebody else is writing it. The same gap drives the number on what a website costs.
Can a website be built in a week?
A small brochure site can, if the content already exists, the decisions are made by one person who is available, and nothing has to connect to anything else. Those three conditions are doing all the work in that sentence. The build is rarely the slow part. Approvals and content are.
Does a redesign take less time than a new site?
Not usually, and often more. A new site has no history to preserve. A redesign has existing URLs that are ranking, existing content to audit, and redirects that have to be mapped so the rankings survive the move. That mapping work is invisible to the eye and it is not optional. Skipping it is how sites lose traffic on launch day.
Why does the launch itself need time booked?
Because going live is a process, not a button. DNS changes propagate, certificates issue, forms need testing on the real domain rather than a preview one, analytics needs verifying, and the link preview card needs checking on the platforms that cache it. Our launch checklist walks the whole thing. Launching on a Friday afternoon is how a small problem becomes a weekend.
What can we do to make it go faster?
Three things, in order of impact. Have the content ready, or pay for it to be written. Nominate one decision maker who can approve without a committee. Answer questions within a day rather than a week. A project with those three in place moves at roughly the speed of the work. Without them it moves at the speed of the slowest inbox.
Related guides and services
What a small business website costs
The factors that actually drive the number, explained honestly.
Website launch checklist
What to verify before and after a site goes live.
Website maintenance checklist
What to check weekly, monthly and yearly.
Small business web design
Design and build a site that explains your business and brings in enquiries.
Website redesign
Rebuild an existing site without losing the rankings you already have.
Website development
The build itself: structure, code, forms, and the systems behind the pages.
Get a Quote
Want a realistic schedule for your project?
Tell us what the site needs to do and what content you already have. We will map out the stages and tell you honestly where the delays are likely to come from.