Websites & support / Explainer
How long does a small business website take to build?
A website can be ready to build while the business is still deciding what it wants to say. The layout is agreed, but the service details need checking, the photographs have not arrived and two people have different ideas about the opening page. Those decisions affect the launch date.
When you ask how long your website will take, I want to look at the actual job first. A small service site and a shop with product records, shipping rules and payments have different things to finish. Giving them the same promise would tell you very little.
The useful answer is a timetable for your build, with a first version we can describe and the responsibilities beside it. Here is what I would put into that plan.
Decide what has to be there on launch day
List the pages and customer journeys the first version needs. For a service business, that may be a clear explanation of the work, its service area and an enquiry route. A shop also needs usable product information, delivery options and a checkout that has been checked from beginning to end.
Separate those requirements from ideas that can follow. If an appointment can still be requested through the agreed contact route, a more complex booking system might be a later phase. If taking online bookings is the reason for the build, it belongs in the launch requirements.
Keep that decision visible. Otherwise an extra feature can arrive halfway through the job without anyone revisiting the delivery date or cost.
Put the content on the timetable
Service descriptions, prices you are willing to publish, photographs and contact details all need somebody to provide or approve them. If we are helping with the writing, we still need your knowledge of the business and confirmation that the details are right.
Name those inputs in the plan. A page waiting for a photograph may be able to progress with a temporary layout. A booking page waiting for cancellation rules has a more substantial gap. Knowing the difference helps us keep the useful work moving.
Choose one person to bring the business’s feedback together. That gives us a clear decision when comments conflict, and gives you one place to see what is still outstanding.
Use the prototype to settle the important choices
Our process starts with a conversation and a prototype. Seeing the pages makes it much easier to judge the structure, the wording and how a customer will move through them. It is also a good point to find a missing service or a step that feels awkward.
Make the feedback specific. “The phone number should be easier to find” gives us a useful change to make. “Something feels wrong” needs another conversation before the build can move on.
Ask for the dates when you will receive the prototype, when feedback is needed and what approval allows the next stage to start. If you know a decision maker will be away, put that in the plan early.
Source: Flying Penguin: how it works
Allow for the systems behind the page
A form, payment step or booking calendar has work behind it. We need the right accounts and settings, the rules for what should happen and a safe way to try it. An attractive button cannot finish those arrangements for you.
For a shop, test orders can trigger emails and connected services. WooCommerce’s testing guidance recommends appropriate test facilities and explains those side effects. Agree which records and notifications are safe to create while the build is being checked.
If another supplier needs to provide access or change a setting, name that dependency. It may be outside the person building the website’s control, but it still belongs on the delivery plan.
Source: WooCommerce: testing orders
Give testing its own stage
Leave time to use the site as a customer. Open it on a phone, follow a service link and send an agreed test enquiry. Check what reaches the inbox and whether a reply goes to the right place. For a shop or booking system, follow the saved records as well as the visible screens.
Accessibility checks need attention during the build too. W3C recommends integrating that work into production. Its Easy Checks cover useful starting points such as keyboard access, headings and form labels, while making clear that these alone do not amount to a full assessment.
Agree which faults prevent launch and who confirms they are fixed. A failed contact form needs a different decision from a photograph you would prefer to replace later.
Source: W3C: planning and managing accessibility; W3C: Easy Checks
Ask for a timetable you can use
The plan should show what happens next, what is needed from you and what could move the date. It should also say how changes to the first version will be handled. That is more useful than a number of weeks with no explanation behind it.
If you have a fixed event or opening date, tell me at the first conversation. We can look at the essential pages and decide whether a smaller first launch would meet it. I would want that discussed before you commission a larger build.
- What will customers be able to do in the first version?
- When will we see the prototype, and who approves it?
- Which content, account access and business decisions are still needed?
- Which connected services or other suppliers affect the timetable?
- What will be tested before the site goes live?
- What can be added after launch without delaying the first useful version?
Sources
Checked on 23 October 2026.
- Flying Penguin: how it works
Our conversation, prototype, build and launch process. Delivery dates are agreed for the individual scope.
- WooCommerce: testing orders
Safe test setups and the emails and connected actions that test orders may trigger.
- W3C: planning and managing accessibility
Accessibility responsibilities, evaluation during production and ongoing attention.
- W3C: Easy Checks
Useful preliminary keyboard, content and form checks, with the limits of a first review.