How long does website development take?
As long as is genuinely needed for the agreed scope, preparing content, development and testing. A straightforward introductory site may be ready sooner than a multilingual service website or complex booking system. But “ready in a week” doesn't tell you what will actually be complete: a design mock-up, a test version or a working website that's been properly handed over.
A website developer does more than write code. Projects also involve decisions, copy, images, access permissions, approvals and tested customer journeys. Without clear responsibilities and deadlines for these, an apparently quick build can turn into a long wait. This guide sets out a process a client can follow, not a universal delivery guarantee.
Three website development stages clients can follow
1. Discussion and planning
Business goals, content, functions and approval milestones.
2. Build and refinement
Design, development, content and shared feedback.
3. Testing and handover
Mobile functionality, contact process, launch and access credentials to be handed over.
- Define the main goal New leads, quote requests, service presentation or bookings.
- Prepare existing materials Logo, photos, services and contact details—whatever you already have.
- Choose who approves the work Make clear who makes the decisions about copy, design and launch.
Seven stages of website development – who delivers what?
These seven stages aren't seven separate tasks for the client. The developer should lead the process while you know when decisions or materials are needed from you.
| Stage | What gets produced? | What must the client provide? | When can it be accepted? |
|---|---|---|---|
| 1. Goals and offer | Sitemap, feature list and agreed deliverables | Services, audience, main goal and decision-maker | A written scope both sides understand the same way |
| 2. Content gathering | Final copy outline, image list and basic details | Accurate facts, logo, photos and contact information | Approved content outline and outstanding-items list |
| 3. Structure and design | Page layout, navigation and mobile view | Consolidated feedback by the agreed deadline | Approved mobile and desktop page templates |
| 4. Development | Pages, forms, functions and measurement capabilities | Appropriate access to required third-party services | Functions usable in a test environment |
| 5. Content entry | Real images, copy and contact details | Approval of copy and imagery | Checked business facts and approved content |
| 6. Testing and fixes | Mobile tests, form trials and issue tickets | Acceptance testing on an actual phone | Issues closed and primary customer journey working |
| 7. Launch and handover | Live website, access register and documentation | Final approval and assignment of responsibility | Public website and permissions handed over |
“Accepted” in the table means that the work can be shown, tested and reviewed. Agree beforehand on who checks completed elements and which issues must be fixed before launch. Some stages can overlap, but not all. Code can be prepared before final copy, for example, whereas an unfinished service list and changing menu structure can cause major rework later.
What determines the actual deadline?
How prepared your content is, what features are needed and how decisions are made together have the greatest effect on timing. The following durations are illustrative planning examples, not market averages or delivery promises from Kaluzsa. The actual schedule is agreed around the scope and approval milestones.
| Project type | Illustrative duration | What determines it? |
|---|---|---|
| Single-page business website | 1–3 weeks | Business details, offer copy, necessary images and a clear contact method. |
| Multi-page business website | 3–6 weeks | Service descriptions, content structure, custom design and approvals. |
| Complex web solution | 6–12 weeks or more | Integrations, custom admin, multilingual content, specialised processes and thorough testing. |
These are not automatic delivery commitments. Well-prepared projects may progress faster; complex work or changes during development can take longer. The quotation should clearly define prerequisites for starting, client feedback times, testing and exactly what “handover” means.
Pages, decisions and custom features
Five pages don't necessarily mean five times the work of one page. A reusable service template may be quicker than a single complex calculator. Count content types, languages, integrations, automated workflows and states that need testing separately.
Content creation and approval
Businesses often haven't collected exact service names, geographic areas, usable images or the contact process. These facts cannot responsibly be invented. If copywriting is included, define the interview, outline, fact-checking and final approval as separate steps.
External providers and technical dependencies
Domain, DNS, email, invoicing, booking, newsletters and analytics may all have separate dashboards. If access is missing, permissions are inadequate or a third party must approve integration, that's not the same as the developer's own working time. Identify which dependencies affect the agreed deadline in the quote.
Scheduling example: how should a client plan?
Let's use a a fictional local business offering five services. This task list is a manageable project model, not a timeline promise. The agreement should set actual dates and work requirements.
- Before starting: agree on the site's purpose, page list, images, contact process and the point of contact.
- First milestone: a sitemap ready for approval and a list of missing content; the client gives consolidated feedback in one place.
- Second milestone: the developer shows a version containing real copy that can also be tested on a phone.
- Third milestone: test contact forms, contact details, mobile menu and links together.
- Handover: live website, backup, domain and hosting access register, and a written list of outstanding tasks.
The key question: when is each milestone considered complete? A design sent by email isn't the same as a design the client has approved. Keep clear, traceable confirmation.
When it comes to your own business
Website development goes more smoothly when the process is clear
You don't have to become a project manager to get a business website. Agreeing requirements, materials and approval points beforehand makes collaboration more predictable.
What should you prepare before requesting a quote?
You can send this list straight to your website developer. Not everything needs to be perfect, but indicate which points are still undecided.
- Accurate business name, contact details, towns or service area.
- Main services, with one sentence explaining whom each helps.
- The customer's intended action: call, form, appointment, quote or purchase.
- Existing website and domain, if any; who controls access.
- Logo, brand colours and authentic photos of your business.
- Common customer questions, approach to pricing and service terms.
- Who approves the copy and has the final say?
- Which external tools must be connected, and who controls them?
- Who reviews service descriptions, prices and contact details before launch?
- Is there a specific campaign or seasonal launch date, and why does it matter?
- Who maintains the website after launch?
- How much scheduling contingency remains before the campaign or opening date?
If missing information reaches the developer later, document how the deadline might change. Preparation isn't pointless administration: it reduces the risk of publishing incorrect information.
What should you do if the project slips?
First identify the blocker: missing approval, newly requested feature, inadequate access or a demonstrated defect? Then agree on one responsible person, a written next step and a revised date. This isn't about blaming one party: the developer must communicate clearly, and the client needs time to make decisions.
| What happened? | What should you ask? | Useful next step |
|---|---|---|
| Content missing | What do we need to finish this page? | Specific missing-items list, one owner and a new approval date |
| New feature requested | Was it in the original scope? | Separate quotation and revised timeline |
| Design differs from expectations | Is there an approved reference or design? | Issue list and one consolidated round of feedback |
| External account inaccessible | Who's the real administrator, and what permissions are required? | Access via an authorised person, not passwords circulated around |
| Functional defect | On which URL, device and step does it happen? | Reproducible test and written fix status |
If the deadline is business-critical, separate essential launch functions from nice-to-have features that can wait. Working contact options, site availability and fixing fundamental technical errors are part of a proper launch.
When is the website genuinely finished?
Not when an impressive homepage appears. Before accepting a business website, test at least: menu and internal links; readability on a real phone; successful and failed form submissions; phone and email links; company details in the footer; page titles and sharing previews; images; secure HTTPS; and backup and access arrangements.
For a new website, also check that no noindex, incorrect canonical or blocking robots directive remains from staging. That still doesn't guarantee Google indexing or rankings. The Search Console beginners' guide guide can help with subsequent checks.
The article on comparing website design quotes explains separately which handover requirements should be written into the agreement. This article focuses on delivery stages and client preparation.
Frequently asked questions
Can a simple business website be built quickly?
Yes, if the scope is small and materials, decisions and access are available in advance. But determine the actual deadline from the specific scope and capacity, not a generic average.
Can we launch before every sentence is perfect?
Only if the remaining issues aren't misleading and essential service information and contact options work. The “we'll fix it later” list must have an owner and a deadline.
Do I need to write the text myself?
Not necessarily. The quote should state who drafts the copy, who checks the business facts and how many revision rounds are included.
Will I appear on Google on launch day?
It's not guaranteed. Publishing, crawling, indexing and ranking are separate processes. Technical checks are necessary but don't mean automatic visibility.
Sources and further reading
Open official sources
Related Knowledge Base articles
Next step · Kaluzsa
Want a website project you can plan around?
Tell me what kind of website you need and which deadline matters. We can discuss the scope and delivery schedule based on your specific requirements.