A website timeline has two important finish lines
When someone says a website takes one week or six weeks, ask what that estimate ends with. A staging review and a public launch are different milestones. Staging means the planned pages are assembled at a private address so the owner can test the experience and request agreed revisions. Launch happens after approval, final checks and the necessary domain or hosting work.
| Milestone | What is normally complete | What may still remain |
|---|---|---|
| Ready for staging review | Page structure, written content direction, responsive design, development and the main enquiry path | Owner feedback, scope-aligned revisions, final approval and launch access |
| Ready for public launch | Approved pages, tested links and forms, metadata, domain connection and production checks | Ongoing measurement, content improvements and future additions |
A clear proposal should identify both milestones. This prevents a fast design promise from being mistaken for a guaranteed live date and helps everyone understand which decisions belong to the designer and which depend on the business owner.
The build starts when the useful material is ready
A short intake is valuable because it collects the decisions that shape the website before design begins. The designer needs to understand the services being promoted, the people the business wants to attract, the service area, the strongest proof and the next action a visitor should take.
- The confirmed website scope and page list
- Accurate service descriptions, prices or quoting rules where relevant
- Business details, opening hours and service areas
- Logos, brand assets and original photographs that are ready to use
- Approved testimonials, licences, memberships and guarantees
- Domain, website and email access where the launch requires it
- One nominated decision-maker and an agreed feedback process
Structure and copy direction come before visual polish
The first working stage turns the intake into a customer journey. That means deciding what the opening screen must communicate, how services should be grouped, which proof belongs near each claim and where an enquiry should become the obvious next step.
For a focused local service website, this work can happen quickly when the offer is already clear. If the business serves several unrelated audiences, has overlapping service names or cannot decide which work it wants more of, the strategy stage needs more discussion. Starting the design before resolving those questions tends to create expensive changes later.
Design and development work best as one connected process
Once the structure is settled, the website moves into visual design and development. On a small project these activities do not always need separate approval rounds. Designing in the browser allows the real content, mobile layout, spacing, interactions and enquiry flow to be considered together.
| Area | Questions being resolved | Typical output |
|---|---|---|
| Visual direction | Does the design feel appropriate for the owner, service and customer? | Typography, colour, imagery, page rhythm and reusable interface patterns |
| Responsive build | Does every page remain clear and usable on phones, tablets and larger screens? | Flexible layouts, readable text, navigation and touch-friendly actions |
| Enquiry path | Can a suitable visitor understand what happens next and provide useful details? | Calls to action, contact information and a proportionate enquiry form |
| Search foundations | Can search engines crawl, interpret and connect the important pages? | Page titles, descriptions, headings, internal links, structured content and sitemap coverage |
Speed should come from a focused scope and a repeatable process, not from skipping responsive checks or filling pages with placeholder copy. The goal of a short schedule is a coherent first version that can be judged as a real website.
A staging review turns opinions into specific decisions
At staging, the owner should review the website as a customer journey rather than commenting on isolated screenshots. Test it on a phone, follow the navigation, read every service statement, submit the enquiry form and confirm that names, claims, contact details and service areas are accurate.
- Collect feedback from all stakeholders before sending it to the designer
- Separate factual corrections from personal preferences and new scope
- Explain the problem a requested change should solve
- Check real devices instead of relying only on one desktop browser
- Approve final wording for regulated, technical or sensitive claims
- Confirm that every phone number, email address and form destination is correct
Consolidated feedback is usually faster to implement and easier to verify than a stream of conflicting messages. If two included revision rounds are available, use the first for substantive corrections and the second for final refinement rather than introducing an entirely new direction at the end.
Launch is a technical handover, not just a publish button
After approval, the website is connected to its public domain and checked in the production environment. The exact work depends on whether the business is keeping an existing domain, moving from another platform, changing email settings or replacing an older website.
- Confirm the approved version and final payment terms
- Connect the domain without disrupting business email records
- Check secure HTTPS loading and the preferred website address
- Test navigation, forms, phone links and important external links
- Confirm titles, descriptions, indexing instructions and sitemap access
- Redirect important old addresses when an existing site is being replaced
- Verify analytics or search tools only when they are included and configured
A new website can be live before Google has revisited every page or before meaningful performance data exists. Search visibility, customer behaviour and enquiry quality should be reviewed over time. Launch creates the foundation for that work rather than finishing it forever.
Most delays are decisions, dependencies or added scope
Good production planning reduces delays, but it cannot remove every dependency. A useful timeline leaves room for the realities of running a business while making ownership of each next step visible.
| Delay | Why it matters | How to reduce it |
|---|---|---|
| Missing content or photographs | The layout cannot be finalised around unknown material | Supply the essentials before day one and identify anything that can follow after launch |
| Several uncoordinated reviewers | Feedback conflicts and decisions are repeatedly reopened | Nominate one person to consolidate and approve comments |
| New pages or functionality | The original structure, design and testing scope changes | Record additions separately and agree on price and timing before work begins |
| Unavailable account access | The domain, hosting or form destination cannot be configured | Locate logins early and confirm who controls each service |
| Late factual changes | Approved sections need to be rewritten and retested | Verify services, prices, locations and claims during intake |
Small-business website timeline FAQs
Can a professional small-business website really be built in one week?
A focused five-page website can often reach staging review within one week when the scope is clear, the required material is available and one person can make decisions. That estimate should not be applied to large websites, online stores, complex integrations or projects that still need extensive brand and content strategy.
Does the one-week timeline include revisions and launch?
Not necessarily. In Dustin's current package, the website is typically ready for staging review within one week after the focused intake and receipt of the required material. Revision timing, final approval and launch access affect the public launch date.
How long should I allow for feedback?
Set aside a defined review window in advance. One or two focused business days may be enough for a small site when one person consolidates comments, but teams with several approvers should allow longer. The proposal should state how feedback and revision rounds are handled.
Can the website launch if some photographs are not ready?
Sometimes, if the missing images are not essential to trust or understanding and both parties agree on an appropriate temporary approach. Do not launch with misleading stock imagery or unresolved placeholders. It may be better to adjust the first scope or wait for the important assets.
Will changing my domain delay the project?
It can if the login is unavailable, ownership is unclear or email records are not documented. Confirm domain access early. A careful launch should preserve the records used by business email and other services.
What happens after launch?
The site should be monitored for form delivery, broken links, indexing and real customer behaviour. Future changes can then respond to evidence such as new services, repeated customer questions, search queries and enquiry quality.