How long does it take to build a website in 2026?

Most websites take between 2 weeks and 6 months to build. A simple brochure site typically takes 2–4 weeks, a custom business site with a CMS 6–10 weeks, an ecommerce store 8–16 weeks and a custom web app 3–6 months. Content and decisions, not code, usually set the pace. Apps add store review and testing waits.

Those ranges are typical planning ranges from the kind of projects we deliver, not a promise: your timeline depends on scope, how ready your content is and how quickly decisions get made. This guide breaks each type of site into phases whose durations add up to the totals, lists what actually slows projects down, and adds the fixed waits that most timeline articles skip: Google crawling after launch, Apple App Review and the Google Play closed test for new developer accounts. Every platform figure links to the official page it comes from, checked on 23 October 2026.

How long does each type of website take?

Two things explain most of the spread inside each row. The first is design: a template adapted to your brand is quick, while a custom design system with its own layouts and components adds weeks. The second is everything that isn't code: content, product data, approvals and third-party accounts. A five-page site can take two months if the copy isn't written, and a 40-page site can go live in six weeks if everything is ready on day one.

If you are comparing quotes, line them up against this table. A quote far below the range usually means a template with your logo on it; one far above may include strategy, copywriting, photography or migrations that others leave out. Neither is wrong, but you should know which you're buying.

How do the phases add up?

A timeline you can trust is built from phases, and the phases should sum to the total. Here is a custom business site with a CMS, the most common project type, broken down the way we plan one.

The arithmetic: 1 + 1 + 1 + 2 + 1 weeks at the fast end is 6 weeks; 1 + 2 + 2 + 3 + 1 at the slow end is 9 weeks, and launch plus a buffer for one late decision takes it to about 10. Phases 2 and 3 can overlap when copy is ready early, which is the single easiest way to save a week.

An ecommerce store has more moving parts, and some of them can run in parallel:

Counting only the steps that can't overlap, the fast end is 1 + 2 + 3 + 1 + 1 = 8 weeks, and the slow end is 2 + 3 + 6 + 2 + 2 + 1 = 16 weeks. The product data track usually decides which end you land on: a clean spreadsheet of 200 products is days of work, while 5,000 products with variants, images and old URLs to redirect is a project of its own.

A custom web app or portal follows the same pattern at a larger scale: 2–4 weeks of discovery and requirements, 2–4 weeks of UX and interface design, 6–14 weeks of development in sprints, 2–3 weeks of testing and user acceptance, and about a week to launch. That adds up to roughly 13 weeks at the fast end and 26 at the slow end, which is where the 3–6 month range comes from.

What slows a website project down?

In our experience the delays are rarely technical. These are the usual causes, roughly in order of how often they move the launch date:

1. Content isn't ready. Copy, photos, team bios, case studies and product data arrive late or arrive in pieces. Build can't finish without real content, and QA on placeholder text misses real layout problems.
2. Slow or crowded feedback. Five people commenting on a design in separate emails turns one round into four. Name one decision-maker and agree a turnaround time for each review.
3. Scope that changes mid-project. A new section, a booking system or a second language added after design sign-off pushes everything behind it. Park new ideas in a phase-two list.
4. Integrations. CRMs, booking tools, ERPs, payment gateways and single sign-on each depend on someone else's API, credentials and test environment. Get access sorted in week one.
5. Migrations. Moving content, products or customers from an old site, and mapping every old URL to a new one, can take as long as the build. Our website migration team plans this as a separate track, and our website migration checklist shows every step.
6. Third-party approvals. Domain and DNS access held by a former agency, payment provider underwriting, legal review of privacy terms and brand approvals all sit outside the project team's control.
7. Accessibility and performance fixed at the end. Building to accessibility and speed targets from the start is quicker than retrofitting them after QA finds problems.

When will Google index my new website?

Launch day is not the day you appear in search. Google has to discover, crawl and process your pages first. Its own guidance on asking Google to recrawl your URLs says: "Crawling can take anywhere from a few days to a few weeks." It also warns that "Requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all."

What you can do on launch day:

• Verify the site in Google Search Console and submit an XML sitemap.
• Use URL Inspection to request indexing for the home page and your most important pages. There is a quota for individual URL requests, so don't resubmit the same page repeatedly.
• Link to the new site from your social profiles, business listings and any existing sites you own.
• Make sure no staging "noindex" tag or blocking robots.txt rule survived the launch.

Being indexed is not the same as ranking. A brand-new domain usually needs months of useful content and links before it ranks for competitive terms. If you are replacing an existing site, the risk is different: you keep your history only if old URLs redirect properly, which is why migrations need their own plan.

How long does it take to build an app?

Apps follow the same phases as websites, plus platform rules that add fixed waiting time. Typical planning ranges for the build itself: a basic app takes 1–2 months, a medium app with accounts, payments or bookings 2–4 months, and a complex app 4–6 months or more, after 2–4 weeks of discovery and design.

Then come the waits you can't negotiate:

The closed-test rule is the one that catches teams out. If your Google Play account is a new personal account, 14 days is the minimum, and the clock only runs while at least 12 testers stay opted in. Planned well, it overlaps with final QA and costs nothing. Discovered at submission, it adds two weeks to the launch. For the full stage-by-stage view, see our guide to the mobile app development process.

How can you speed things up without cutting quality?

• Write the content first. Even rough copy for every page lets design and build use real text, and stops QA being repeated later.
• Decide what launch needs. Separate must-haves from phase-two features. A focused first release that goes live in eight weeks beats a perfect one that ships in six months. Our MVP development work starts from that list.
• Name one decision-maker and agree a 48-hour turnaround for each review round.
• Use a proven platform where it fits. A Shopify, WordPress or Webflow build reaches launch faster than a fully custom stack when your requirements are standard.
• Run tracks in parallel. Content, product data, store accounts and integrations credentials can all move while design is in progress.
• Book testing time in advance. Plan who will test on which devices, and when, before the build starts.
• Sort access in week one: domain registrar, DNS, hosting, analytics, payment provider and app store accounts.

What not to cut: discovery, QA and a proper launch checklist. Skipping them rarely saves time; it moves the work to after launch, when fixing it costs more.

How should you read a timeline in a quote?

Ask every agency for the same three things, so you can compare like with like:

1. A phase plan with start and end weeks for each phase, and which phases overlap.
2. Your dependencies: what you must supply (copy, images, product data, access, feedback) and by when, and what happens to the date if it slips.
3. What "launch" includes: redirects, analytics, search console setup, training for your editors and a support window after go-live.

A single end date with no phases and no dependencies is a guess. A plan that names your responsibilities is one you can actually hold the team to.

How can Elgrith help?

Elgrith has delivered 1,000+ projects for 250+ clients since 2015, from our New Delhi headquarters and client centers in New York, London and Shanghai. Our website design team plans every project phase by phase, with a fixed written quote and a timeline agreed in your written scope. In the UK, see our web design in London page; in India, our Gurugram web development service runs from our New Delhi HQ. Agencies can hand us builds under their own brand through white label web development, and for products we cover app development and MVP development. Book a call or start a project.