“How long will the website take?” is usually the question immediately after price.
The useful answer is not “three days” or “six weeks.” It is a timeline tied to what has to be true before the website is actually ready for customers.
For a Nigerian business in 2026, I would use these planning windows:
| Project | Realistic planning window | What usually controls the date |
|---|---|---|
| Focused landing page | 1–2 weeks | Copy, one offer, form, tracking, approval |
| Small business website | 2–4 weeks | 5–8 pages, content, responsive build, forms |
| Lead-generation business website | 3–6 weeks | Positioning, custom layouts, service pages, analytics, testing |
| Ecommerce / booking website | 6–12 weeks | Products, payments, delivery or scheduling rules, testing |
| Website redesign with migration | 4–10 weeks | Audit, content decisions, redirects, CMS migration, QA |
| Custom web application | 8–20+ weeks | Roles, data, integrations, workflows, security and testing |
These are planning ranges, not promises. A five-page website with finished copy can launch faster than a three-page site where nobody has agreed what the business actually sells.
The calendar is not the same as developer working hours
A project can contain five working days of implementation and still take three weeks on the calendar.
Why?
Because website projects contain waiting:
- waiting for the About page;
- waiting for new photos;
- waiting for the owner to approve the homepage;
- waiting for a domain transfer;
- waiting for Paystack or another provider to verify an account;
- waiting for a second director to review something the first director already approved.
If the deadline matters, manage the waiting as deliberately as the design.
A realistic six-week business website
For an established service business, I would expect something close to this.
Week 1: discovery and structure
We define the business goal, audience, main conversion action, pages, proof, services and any integrations.
This is where “we need a website” becomes a real scope.
A professional site should answer questions such as:
- Who is this for?
- What should the visitor understand first?
- What should they do next?
- Which services need their own pages?
- What proof can we show?
- Who receives enquiries?
- Which accounts and tools must connect?
Skipping this stage can make development feel faster while creating more revisions later.
Weeks 1–2: content
Copy and imagery are often the real critical path.
A homepage design cannot solve an offer that nobody can explain. A hotel gallery cannot sell rooms if the hotel has not supplied usable room photos. A school admission page cannot be completed when fees, dates and application steps are still being debated internally.
Content preparation should begin before the visual design is finished.
Weeks 2–3: design
The designer establishes the visual system and the important page layouts.
A useful approval pattern is to agree the direction on one or two representative pages before designing every page. That reduces the cost of changing direction later.
Weeks 3–5: development and integrations
The approved design becomes a responsive website.
This includes more than reproducing a desktop screenshot. Navigation, mobile layouts, forms, validation, analytics, CMS behaviour and third-party tools all need to work.
Week 5–6: QA and launch
I would test at least:
- mobile and desktop layouts;
- contact forms and email delivery;
- WhatsApp, phone and booking actions;
- analytics and conversion events;
- titles, descriptions and canonical URLs;
- redirects where an old site is being replaced;
- important browser/device behaviour;
- domain, SSL and production configuration.
If the site is new, Google explains that crawling and indexing can take time and that submitting a sitemap or requesting indexing does not guarantee instant inclusion. Use Search Console after launch instead of promising that a new site will “rank immediately.” See Google’s crawling and indexing FAQ.
Why ecommerce takes longer
An ecommerce website is not only a catalogue.
The product has to make correct decisions around:
- variants;
- stock;
- prices;
- discounts;
- delivery;
- payment success and failure;
- order state;
- customer notifications;
- returns or cancellations where relevant.
The visible checkout may be simple. The state behind it is what takes testing.
If your project mainly revolves around cost rather than timing, use my website design cost in Nigeria guide before collecting quotes.
Why redesigns can take longer than new sites
A new site starts with an empty room.
A redesign may inherit:
- indexed URLs;
- old content;
- analytics;
- forms;
- existing customers;
- plugins;
- email setup;
- redirects;
- third-party integrations.
That existing value has to be protected.
For a redesign, I would rather spend an extra week auditing what already works than launch quickly and discover that the new site broke enquiries or removed pages that were bringing search traffic.
See repair vs redesign vs rebuild if the scope is not yet clear.
Five things that make a Nigerian website project faster
1. One decision-maker
Stakeholder input is useful. Five people approving every paragraph is not.
Choose one person who can resolve conflicting feedback.
2. Content before development
Prepare services, addresses, phone numbers, team profiles, prices where public, photos, testimonials and legal information early.
3. Account access before launch week
Domain registrar, hosting, analytics, email and payment accounts should not be mysteries at the end of the project.
Ownership also matters after launch. My website ownership guide explains which accounts I would keep under the business’s control.
4. A frozen first release
When a new idea appears, ask whether it must block launch.
Often the right answer is no.
5. Feedback with decisions
“Make it better” is slow feedback.
“Use option B because our primary customer is the property owner, not the tenant” gives the project a direction.
Be suspicious of both impossible speed and unnecessary delay
A developer promising a complex ecommerce site in 48 hours may be ignoring work that should be done.
A developer asking six months for a simple brochure site may have a capacity problem rather than a technical one.
The right timeline should explain:
- the scope;
- dependencies;
- review points;
- what the client must supply;
- what counts as launch-ready.
If you have a fixed launch date
Tell the designer before the scope is finalized.
A fixed date changes the product decision. We may need to reduce the first release, launch a landing page first, keep a manual process temporarily or postpone a non-essential integration.
That is better than pretending everything fits and missing the date anyway.
If you need a website for a launch, school term, hotel campaign, event or business opening and the date is not flexible, send me the deadline and the required outcome. I can help define the smallest version that can responsibly go live on time.
