How Long Does It Take to Build a Business Website?

Most corporate and marketing websites we build take 4–8 weeks from kickoff to launch. That range, already on our website development FAQs, assumes content is not the bottleneck. When copy, product photos, and legal pages arrive in week six, the calendar slips even if engineering is on track.

A typical 4–8 week sequence

1. Week 1: discovery, sitemap, technical constraints, hosting/DNS plan.
2. Weeks 2–3: wireframes and visual design for key templates; one structured feedback round.
3. Weeks 3–6: build, CMS, forms, integrations, content entry, internal QA.
4. Weeks 6–8: client UAT, redirects, analytics, SSL, launch, handover.

Campaign landing pages can be faster if the offer, copy, and tracking are ready on day one. Ecommerce catalogues, multilingual sites, and migrations from a ranked old domain take longer because redirects and content mapping are the work - not because developers type slower. A store with a few dozen SKUs is a different calendar from a brochure site even when both are “websites.”

Kickoff is not the day you signed the PDF. Kickoff is the day access, brand files, and a decision-maker calendar exist. If those arrive late, the 4–8 week clock has not started. We would rather say that plainly than pretend a silent inbox is “development delay.”

What you should have ready on day one

• Brand basics: logo, colours, type, any existing UI kit
• A page list with who owns each page’s copy
• Examples of sites you like and why (layout, tone, not “make it modern”)
• Access to domain DNS and current hosting if we are migrating

Name one approver for design and one for copy. Committees that “all need to see it” add a week per round without improving the site. If legal must review claims, put them in the sequence on week one, not the day before launch. If photography does not exist, decide whether to use existing assets, a stock budget, or a shoot - waiting until the template is coded wastes both sides.

For migrations, export a URL list from the current site (or a crawl) before design starts. Redirects are a project, not a checkbox. Old PDFs, campaign URLs, and “temporary” pages that rank will 404 unless someone inventories them.

Why timelines blow up

Unclear approvers, unlimited design revisions, and “can we also add a portal” mid-sprint. We timebox design rounds and treat new modules as change requests so the original launch date stays honest. If you need a portal or app, that is a web application track, not a website week.

Content delay is the most common slip we see. Engineering can build templates against placeholder copy. They cannot magically invent your service descriptions, GST-legal footer, or team bios. Parallelise: while design is in review, start writing. If writing cannot start, reduce v1 pages rather than hoping week eight will compress six pages of unwritten copy.

Integrations slip when the other vendor does not provide sandbox keys. Payment, CRM, and booking tools need a named contact on that side. Put that in the kickoff checklist. A form that “just emails us” can launch on time; a two-way CRM sync that nobody has documented cannot.

Launch is a checklist, not a moment

Launch week is DNS, SSL, redirects, analytics, form tests on the live domain, and a rollback plan. Doing those on a Friday evening with no access to the registrar is how “we went live” becomes “email is down.” We schedule launch when the people with DNS access are reachable, then watch forms and uptime for a short hypercare window.

Handover should include how to edit, where backups live, and who to call. A site without that is not finished, even if it looks done. Maintenance from ₹5,000/month (as published on our support offering) is how the next plugin update does not become an emergency rebuild.

How to recover a slipping calendar

Cut v1 pages, do not ask engineering to “work nights” as the default plan. Ship the pages that collect enquiries (home, services, contact) and put careers or a long about page in v1.1. Freeze design after the agreed round. Move a late integration to a post-launch sprint if the live site can use a simple form in the meantime. Those are adult trade-offs. Pretending the original 20-page list still fits in the original week-eight slot is how everyone is unhappy and the site is still on staging.

Put dates on your side of the table: copy due, UAT start, DNS window. We can only hit a launch date if those dates are real. If they are not, we will propose a new date rather than a heroic Friday deploy.

If you already have a deadline (campaign, event, funding), say so in the quote request. We would rather phase a v1 than pretend a 20-page rebuild fits in ten days. A smaller, true launch date beats a fictional big-bang date that slips in public.

Straight answers on calendars

Can you do it in two weeks? A campaign landing page with ready copy and no migration sometimes. A corporate site with CMS, legal pages, and a ranked old domain almost never. We would rather refuse a fantasy date than miss it in public. Say the hard date on the quote request and ask what v1 fits.

When does the 4–8 week clock start? Kickoff: access, brand files, and a named approver. Signing a PDF while DNS logins are “with the old vendor” is not kickoff. We will put those dependencies in the plan so you can see whose delay it is.

Why do agencies pad timelines? Because content, legal, and third-party keys are late in real life. A honest 6-week plan with your dates on it beats a 3-week promise that ignores your approval cycle. Our published range on website development already assumes you participate.

What if copy is late? We build templates against placeholders and launch fewer pages. We do not invent your service claims. Reduce sitemap, do not skip QA. Careers and long case studies are the usual v1.1 candidates.

Do weekends count? Not as a planning assumption. Launch windows need registrar access during working hours. Hypercare after launch is a few days of watching forms, not unpaid all-nighters as the default commercial model.

What about ecommerce or portals? Those are different calendars. A catalogue is not a brochure. A portal is a web application. Mixing them into “the website” is the usual reason week eight arrives with a staging URL and a new wish list.

If you want a date you can print on an invitation, bring copy owners, DNS access, and a frozen v1 page list to kickoff. We will put your dates next to ours on one page. That artefact is more useful than a Gantt that assumes nobody goes on leave. Timeline honesty is part of how we sell website development - not a separate “project management add-on.”

UAT is not “looks nice on my laptop.” It is forms on a phone, redirects from old URLs, and a second person who did not design the site trying to edit a page. Budget days for that, not an afternoon. If leadership only reviews on the last evening, the calendar will slip even when engineering was on time. Put UAT on the invitation timeline the same way you put the print deadline.