For a focused small business website — home, about, services, contact, and a page or two more — two to four weeks is a realistic schedule from kickoff to launch. Applications and integrations vary far more widely, and should come with a schedule attached to the estimate rather than a rule of thumb.
That range assumes one thing, which we will get to. First, where the time actually goes.
Where the weeks go
Days 1–3: scope and structure
Before any design happens, someone has to decide what pages exist, what each one is for, what a visitor should do on it, and what information the business needs to supply. This is where a project is won or lost. A build that starts without this is a build that gets rewritten twice.
Output: a page list, a purpose for each page, and a written estimate of hours.
Days 3–8: content and messaging
The words come before the layout, not after. Designing around placeholder text produces layouts that break the moment real copy arrives — headlines that are three times too long, service descriptions that do not fit the box.
The business supplies the facts: what you do, who you serve, prices or ranges if you publish them, service areas, hours, credentials, photos, logo. Shaping that into page copy is part of the work.
Days 8–15: design and build
Layout, typography, responsive behavior, and the actual code. For a static site there is no theme to wrestle with and no plugin stack to configure, which is a large part of why this phase is measured in days rather than weeks.
You should see something real and clickable partway through this phase, not a picture of a website.
Days 15–19: review and revisions
One consolidated round of feedback, then changes. Consolidated matters — feedback arriving in twelve separate messages over ten days turns a two-day task into a two-week one.
Days 19–21: technical setup and launch
Domain and DNS, SSL, hosting, forms tested end to end, page titles and metadata, sitemap, Search Console and analytics, redirects from old URLs if the site is replacing something. Then it goes live.
The thing that actually delays projects
Content. Almost always content.
The design and the code run on a predictable schedule. What does not is the week spent waiting for the business owner to write their About page, find a usable photo of the storefront, or decide whether they offer three services or five. We have seen two-week builds stretch to three months entirely on this.
If you want a fast project, have your material ready before day one:
- A one-sentence description of what your business does and who for
- Your list of services, with a short description of each
- Prices, ranges, or the reason you do not publish them
- Business name, address, phone, email, hours, service area
- Your logo in a vector format if you have one
- Photos of your work, premises, or team — real ones
- Any reviews or testimonials you have permission to quote
- Whoever needs to approve the final result, available to approve it
The build takes two weeks. Waiting for the About page takes six.
What makes a project take longer, legitimately
More pages. A twenty-page site is not four times the design work, but it is roughly four times the content work.
Custom functionality. A contact form is quick. Booking with calendar sync, payment handling, and confirmation emails is a different project with its own testing burden.
Integrations. Anything that has to talk to a system you already run adds time proportional to how well that system is documented.
Migration from an existing site. Preserving URLs, mapping redirects, and moving content correctly is real work, and skipping it is how businesses lose their search rankings overnight.
Multiple approvers. Every additional person with veto power adds a review cycle.
What does not need to take longer
Discovery workshops, mood boards, and three rounds of alternative homepage concepts are normal at agency scale, where the process is partly there to justify the invoice. For a five-page business site they mostly add calendar time. You can see what we would build on the portfolio page rather than paying to find out.
If you are still deciding what the project should cost, the pricing guide breaks down what each tier actually buys.
How to keep it on schedule
Three habits do most of the work: gather your content before kickoff, give feedback in one consolidated pass rather than a trickle, and decide up front who has final approval. Projects that do those three things generally land inside the estimate. Projects that do not are usually late for reasons that have nothing to do with the code.
Want a schedule for your specific project? Tell us what you need and we will send a written scope with estimated hours and dates before any work starts.