Ask five companies how long your website will take and you will get five different answers, which does not mean that four of them are guessing. The question has more moving parts than it looks, and most of those parts sit on your side of the table rather than the developer's. So here are the honest ranges first, then a walk through exactly where the weeks disappear, so that when somebody hands you a date you can tell whether it is a plan or a hope.
The Honest Answer, Before We Explain It
These are the ranges we work to, and nobody should have to scroll to find them:
- A brochure site of five to eight pages: 3 to 6 weeks.
- A business site of 15 to 30 pages with a blog attached: 6 to 12 weeks.
- An online shop: 10 to 16 weeks.
- Anything with customer logins, bookings or payments running through it: 4 to 9 months.
Those are calendar weeks from the day the agreement is signed to the day the site is live and taking real visitors, and they are not hours of work. That distinction matters more than almost anything else on this page, because a site carrying perhaps 120 hours of actual building can still take ten weeks to finish, and the space between those two numbers is where most of the disappointment in this industry lives.
The reason is straightforward enough. Building time is fairly predictable, since a designer knows roughly how long a homepage takes and a developer knows roughly how long a contact form takes. Waiting time is not predictable at all, and waiting time is what usually doubles a project.
Why One Company Says Six Weeks and Another Says Six Months
When two quotes land on your desk with wildly different dates, the instinct is to assume one of them is padding the bill. Usually they simply heard different questions. The six week company is pricing a ready made template with your text and photographs dropped into it, which is a real and perfectly legitimate product. The six month company is pricing a design drawn for your business, tested on actual phones, and connected to the tools you already run your day on.
What genuinely differs between them is worth understanding before you argue about money. Is the design original, or a bought theme that a thousand other businesses also bought? Who writes the words, you or them? Does the site have to talk to a payment provider, a booking calendar, a stock system or your accountant's software, because every one of those connections is days of work and testing rather than a tick in a box? And how many rounds of changes are included before the extra invoices start?
So rather than asking which quote is cheaper, ask both companies the same two questions: what is inside your six weeks that is not inside theirs, and what happens in week seven if we are not finished? The answers will tell you far more than any price list will.
To be plain about it, the cheaper and faster option is genuinely the right choice for a great many businesses. A one person consultancy that needs a credible presence, a clear list of services and a working contact form does not need a four month build, and we say so when that is the case, because a client who spends heavily on the wrong thing rarely comes back for the right one.
Where the Weeks Actually Go, Phase by Phase
Almost every project moves through the same six phases, and each one takes a fairly consistent slice of the calendar:
- Discovery and planning: 10 to 15 percent of the time.
- Design: 20 to 25 percent.
- Preparing the content: 15 to 20 percent.
- The build itself: 30 to 35 percent.
- Testing and fixing: 10 to 15 percent.
- Launch: about 5 percent.
Put real numbers against a ten week business site and it looks like this: about 1 week of planning, then 2 to 2.5 weeks of design, then 3 to 3.5 weeks of building, with roughly 1.5 weeks spent loading in the content, 1 week of testing, and finally 2 to 3 days to go live properly.
In plain language, discovery means agreeing what the site is for and who it is talking to before anybody draws a screen, which sounds like a formality until you meet the project where the owner wanted enquiries and the marketing manager wanted online sales. Once that is settled, design works out what each type of page looks like, usually starting with the homepage before moving on to an inside page and then the shop or blog layout, while content preparation runs alongside it to gather the words, photographs, logos, prices and legal text those pages will carry. The build then turns approved designs into a working site that behaves properly on a phone as well as a laptop, and testing follows as the deliberate hunt for everything that is slightly wrong, before a customer finds it for you. Last comes launch, which means pointing your web address at the new site and takes a couple of days mostly because web addresses and email settings need time to settle across the internet.
The Four Things That Actually Cause Delays
After enough projects you stop being surprised, because the same four causes account for almost every late launch. Here they are in the order we meet them, each with a real cost in days against it so that it stops being an abstract warning:
- Content that never arrives. Comfortably the most common of the four, and waiting on text and photographs typically adds 2 to 5 weeks to the calendar.
- Decisions with no single decision maker behind them. A committee approving designs adds 1 to 3 weeks per round, since four people rarely reply on the same day.
- Scope that grows quietly, one reasonable request at a time. Each addition made in the middle of a project costs 3 to 10 working days, including the ones that sounded tiny when somebody asked for them.
- Third parties working to their own calendar rather than yours. Banks, internal IT departments and hosting companies, which are the firms that rent you the space on the internet where your site's files actually sit, do not know your launch date, so a bank approving a payment account commonly takes 2 to 4 weeks and there is no queue jumping available to anybody.
There is also a compounding effect that catches people out. When a project pauses to wait for you, the team does not sit still, they move on to other client work, so restarting carries a re entry cost of 2 to 4 days while everybody reloads the details of your build. That is why a one week delay on your side usually lands on the calendar as about a week and a half, and why two of those across a project quietly turn ten weeks into thirteen.
Content Is the Silent Killer, and It Is Almost Always Yours
Here is the uncomfortable truth about late projects: in most of them the site was finished and the words were not. The pages sat built and empty while somebody hunted through an old laptop for a folder of photographs, and the launch date drifted for reasons that had nothing to do with the people building it.
The scale of that job is nearly always underestimated, so let us do the arithmetic together. Thirty pages at 300 to 500 words each is roughly 12,000 words, which is about 25 to 40 hours of genuine writing for somebody who does not write for a living, and all of it lands on top of running a business. Then add photography, which takes half a day to shoot and about two weeks to schedule once you have found a photographer and cleared a morning when the premises look their best.
There are three honest routes and each has a price in weeks. You write it yourself, which is cheapest in money and slowest in calendar time. We write it from interviews with you, which adds 2 to 3 weeks to the plan but removes the waiting entirely, because the work moves to somebody whose job it is. Or you launch with fewer pages and add the rest later, which is the option most people should take and the one fewest people consider.
At Linkysoft we usually recommend launching smaller, especially for a small business. A live eight page site is answering enquiries, collecting email addresses and appearing in search results while a perfect thirty page site is still a draft in a shared folder. If you want to see how much of this comes back to words rather than code, our other pieces on content make the same argument from a few different directions.
Scope Creep: How Small Requests Become Whole Months
Scope creep is a phrase often used to blame clients, which is unfair, because it is really just the sum of a series of reasonable small requests, none of which felt like a change at the moment it was asked for. Nobody wakes up intending to add three months to their own project.
A worked example makes it concrete. In week five somebody asks whether customers could book appointments online, and it sounds like one extra screen. What it actually brings with it is a calendar, rules about who is available and when, confirmation emails, the ability to reschedule, a cancellation policy that now has to be enforced by software rather than by good manners, and usually a payment step so that people turn up. That is 3 to 6 weeks of work, not an afternoon.
The rule we use is simple enough that you can apply it yourself. If a request adds a new noun to the project, such as bookings, memberships, invoices, branches or subscriptions, then it is a new phase rather than an edit. Editing means changing something that already exists, and everything else is building something that does not.
The practical fix costs nothing at all. Open a phase two list in week one and put every good idea on it as it arrives, dated, with nobody having to argue about whether it is worthwhile. Most of our projects finish with 8 to 15 items on that list, and that is the healthy outcome, because those ideas were captured rather than lost or forced into a launch they would have delayed. If your list is filling up with logins, dashboards and calculations, then what you are describing has grown past a website into web apps development, and it deserves its own plan and its own budget instead of being squeezed into this one.
What Approvals Cost You, and How to Halve That
Every design and every page needs somebody to say yes, and a yes from four people takes considerably longer than a yes from one. This is the delay that nobody puts in a proposal, and it is also the one that is easiest to fix.
The arithmetic is worth seeing written down. Two rounds of feedback at three working days each comes to six working days, and a ten week project contains only fifty working days in the first place, so roughly 12 percent of your schedule goes on waiting for an email rather than on building a website. Add a fifth person to the approval chain and those six days stretch closer to ten, without anybody having done anything wrong.
Four things genuinely fix it, and none of them costs a penny:
- One named decision maker on your side who can say yes without polling the room.
- Feedback gathered into a single document rather than scattered across messages, calls and sticky notes, because contradictory comments from three people cost a day just to reconcile.
- A 48 hour response window agreed in writing at the start, while everybody is still optimistic.
- A fixed weekly call, because half an hour at the same time every Tuesday settles the small questions that otherwise sit in an inbox until somebody happens to remember them.
The honest point underneath all of that is one clients rarely hear from an agency: faster feedback from you will move your launch date more than a bigger development team would. Two extra developers cannot compress a three day wait for an approval.
Testing, Security and the Boring Week That Saves You
Testing is the least glamorous part of a project and the part that protects you most. It means every form is actually submitted and the message checked at the other end, every page opened on a real phone rather than a shrunken browser window, the speed measured on a weak mobile connection instead of office broadband, the spelling read properly by a human, every link followed, and somebody deliberately typing nonsense into fields to see what breaks.
Here is what that phase normally produces, so that the volume does not alarm you when it arrives. A twenty page site typically throws up 40 to 80 small fixes, of which 2 to 5 genuinely matter. That is normal and it is not a sign of careless work, it is the process doing its job, in the same way that a builder walks a finished house with a snagging list.
Sites that skip this phase still launch, they simply do their testing in public, and that usually costs 3 to 4 weeks of fixing while customers watch. Trading one quiet week of testing for the best part of a month of repairs carried out in front of your customers is a poor exchange, because a visitor who meets a broken checkout does not come back later to see whether you repaired it.
If the site takes a payment or holds customer details, security checks belong in this same phase, and in plain language they mean this: the connection is encrypted so that information cannot be read on its way across the internet, the login area resists people guessing passwords over and over, the software behind the site is up to date, backups exist and have been restored at least once to prove they actually work, and card details are handled by a payment provider rather than stored by you. That last one matters more than most owners realise, and it is the first thing we check. There is more detail in our work on cybersecurity if your site will hold anything you would not want published.
Realistic Timelines by Type of Site
Find yourself somewhere in this list, which is a solid enough basis for a conversation with any company you talk to:
- A one page landing site: 1 to 2 weeks. A landing page is a single page built around one action, such as booking a call or asking for a quote, with no menu of other pages for a visitor to wander off into.
- A brochure site of five to eight pages: 3 to 6 weeks.
- A business site with a blog: 6 to 12 weeks.
- An online shop with up to 100 products: 10 to 16 weeks.
- A booking or customer account system: 4 to 9 months.
- A mobile app built alongside the site: add another 3 to 5 months on top, because it is a second product rather than a feature of the first.
A second language adds 25 to 40 percent to the timeline, and it is worth understanding why, since it is not simply translation. It is a second round of proofreading by somebody who reads that language properly, a second set of page titles and search text, and in the case of Arabic a complete right to left layout in which menus, buttons, forms and tables all mirror and then have to be tested on their own. Treating that as a copy and paste job is the most common way a bilingual site ends up launching with pages that look broken.
Some of these can safely be built in stages and some cannot. A shop can open with 20 products and grow to 200, and a business site can launch with eight pages and add its blog in month three, which is a sensible way to buy back weeks. A payment flow, though, cannot go live half tested, and neither can a login system holding customer records, because those failures are not cosmetic. When we plan web design and development alongside a phone app, we normally launch the site first and let it start earning while mobile apps development runs behind it. Readers weighing up a full shop against something simpler often find our writing on ecommerce useful at exactly this point.
How to Read a Timeline Before You Sign It
Five questions will expose an optimistic quote in about ten minutes, and the way they are answered tells you as much as the answers themselves:
- What are you assuming that I will deliver, and by when?
- What is deliberately not included in this price?
- How many rounds of revisions do I get before the extra charges start?
- Who else is in your queue during my weeks?
- What is your process when a date slips, given that dates do slip?
The clearest tell of all is this. A timeline with no client deadlines written into it is not a timeline, it is a hope, because a real plan says what you owe and when you owe it. The company knows perfectly well that their week six depends on your week four, so if the document contains only their obligations then nobody has thought properly about the part of the project that most often goes wrong.
A healthy proposal has named phases, a start and an end date against each of them, a clearly marked content deadline, and a note of what happens if that deadline passes. It reads like a plan that somebody expects to be held to rather than a brochure written to win the job.
It is also entirely reasonable to ask to see two finished projects of a similar size and to hear what they genuinely took, including the parts that ran late and why. Anybody who has been doing this honestly will have those stories ready, and our own case studies exist partly so that the conversation can start from real examples rather than from promises.
How We Keep Projects on Their Date
Promises are cheap, so here are the mechanics instead. The content deadline goes into the plan as a dated item with your name against it rather than as something mentioned once in a meeting, and because a deadline is only as good as the person who can act on it, we name one decision maker on each side so there is always somebody able to say yes. Both of those are held together by a fixed thirty minute call every week, which runs whether or not anything dramatic has happened, since slippage tends to be discovered late rather than caused suddenly. Alongside all of it sits the phase two list, opened in week one so that good ideas have somewhere to live other than the current build.
We also run phases in parallel wherever they can safely overlap. Gathering your content starts alongside design instead of after it, which shortens the calendar without reducing any of the work, and on a ten week project that alone typically saves 1.5 to 2 weeks. It only works when the content deadline is treated as real, which is why it is the one date we are firm about.
Then there is the part that nobody controls, and pretending otherwise helps no one. A bank approving a payment account commonly takes 2 to 4 weeks, a domain or hosting transfer runs to 3 to 7 days once both sides have answered their email, and an internal IT department asked to change a web address setting often needs 1 to 2 weeks, simply because the request joins a ticket queue behind everything else on their desk. At Linkysoft we plan around those waits by starting them in week one rather than week eight, which is the only reliable defence against a queue you do not own.
Where a project genuinely needs more than a website, we prefer to say so early rather than late. Sometimes that means digital marketing should begin before launch so that the site opens to real visitors instead of silence, and occasionally it means the problem being described is really an automation job for AI systems rather than another set of pages.
So What Should You Do This Week
Three things, before you contact anybody at all. Write down the pages you actually need, which is usually fewer than you think and always clearer once it is on paper. Find out who owns your domain name and who holds the hosting login, because chasing a former web designer for a password is a genuinely common three week delay. And decide who in your organisation says the final yes, then tell them that is their job.
Then hold on to the single most useful piece of advice on this page, which is to launch smaller and sooner. Put a good eight page site live in six weeks, watch what real customers click on, and grow it in the direction they show you, rather than spending five months guessing inside a document that nobody outside your office will ever read.
When you are ready, we are glad to talk your specific project through and send you a timeline with your deadlines written into it as well as ours, because that is the only kind that holds up. You can reach the Linkysoft team through our contact page, or carry on reading on the blog, where we cover the rest of what goes into a site that earns its keep, including the hosting choices that quietly affect your launch date.
