You have been asked for a website for the launch, the trade show or the funding round, and the date is already in the diary. The question comes quickly: how long does it take to build a website, and is four weeks enough? The answers you find online range from "two days with a template" to "six months", which does not help you decide much.
I build websites on my own, on short engagements, and I built this one with Next.js, Sanity and Vercel. In May 2026 I also rebuilt the marketing site of Moonworkers, my own company, on the same stack. What I take from it: a short timeline rarely depends on how fast the code gets written. It depends on decisions and content. Here is how I split four weeks, what I cut to hold the date, and what happens after go-live.
01What really sets the timeline
When a website schedule slips, I look at three things first, and code is not one of them.
The first is content. A site without copy, images and proof is not finished, however good it looks. Copy nearly always arrives last, because nobody blocked out time to write it. On a content production job, I saw that the bottleneck was not the writing but the manual publishing; on a website it is often the reverse: everything is ready except the words.
The second is decision-making. How many people need to approve a mock-up, and how often do they meet? A sign-off waiting for next month's committee costs more than any technical difficulty.
The third is scope. Every feature added along the way (a second form, an English version, a customer area) pushes the date back, and it rarely comes alone.
02What fits in four weeks, and what does not
Four weeks is enough for a brochure site or a launch site: around ten pages, a contact form, a blog or news page, audience measurement and an editing tool the team knows how to use. It is also enough for a first version you will improve afterwards.
It is not enough for a full online shop, a customer area, an ERP connection or a migration of several hundred pages with their redirects. For comparison, the UK government's service manual says that alphas tend to last between 6 and 8 weeks, and that alpha is for testing prototypes, not shipping production code. A site built in four weeks is a deliberate first version, not a finished product.
I prefer to say so at the start. A short deadline is met by taking things out, not by working through the night.
03My plan, week by week
This plan assumes one person who can decide, available for an hour a day, and content written alongside the build. Without those two conditions, I do not promise the date.
Week 1: scope and pick a direction
I start with a few days of diagnosis: who the site speaks to, what we want the visitor to do, which pages must exist on launch day. I come out with a page list, a content plan with an owner for each piece of copy, and the list of what will wait for the next version. I describe this step in more detail in a piece on scoping a digital project in one week.
At the end of the week, I show two or three mock-up directions at the same level of finish. I learned on an engagement that presenting one polished option and two sketches amounts to imposing the first. At the same level, the discussion is about substance, and the decision is made in one meeting.
Week 2: build the structure
I set up the template, the components and the content model in the chosen tool. I use tools I know well: a tight deadline is not the moment to discover a framework. For a Next.js site, the Next.js documentation notes that it can be deployed to any provider that supports Node.js, or through verified adapters such as Vercel; I put a test address online from day one, so everyone can watch the site progress.
If the main user journey raises questions, I test it with a clickable prototype before coding it. Nielsen Norman Group recommends testing with no more than 5 users and running as many small tests as you can, adding users when the site has several very different audiences. Half a day is often enough to find what gets in the way.
Week 3: fill in and connect
Content goes into the site, forms are connected and audience measurement is set up. On that point I check the setup against the CNIL, the French data protection authority: some audience measurement tools can be exempt from consent under conditions (page in French), and others cannot. Better to know before designing the banner.
When the specification still changes with every exchange, I version it. On an integration between an ERP and an online shop, that is what kept everyone talking about the same document.
Week 4: acceptance testing and go-live
The last week is for acceptance testing, not for adding pages. I test every form, every link and every page on mobile, and I measure speed. Google gives precise thresholds for Core Web Vitals: main content displayed within 2.5 seconds, a response to interactions in 200 milliseconds or less, and a layout that does not shift beyond 0.1. My acceptance testing and go-live checklist covers the rest.
Finally, I check the site as a visitor would, logged out, in a private window. I have seen a site look fine to the logged-in team and stay broken for the public because of caching.
04The decisions that cost you weeks
Looking back, lost weeks nearly always come from the same places.
- Copy that is "coming next week" three weeks running. I set an owner and a date for each page at the scoping stage.
- A mock-up approved, then reopened by someone who was not there. The list of people who sign off is decided on day one.
- A "simple" feature added in week three. It goes on the list for the next version, with a date.
- A tool chosen because it is fashionable. I stick to what I know I can deliver, and I say so when another choice would be better.
My early years in audiovisual production taught me to hold a budget, a schedule and a team to a date that does not move. The method is the same here: the date is fixed, and what goes into the release adjusts.
An honest limit: this plan does not work when nobody can decide quickly, or when the site has to carry business features. In that case I would rather announce eight or twelve weeks than hold four by delivering a half-empty site.
05After go-live, Google keeps its own schedule
Your site is live, but it is not in Google yet. That is normal. Google Search Central's documentation says that crawling can take anywhere from a few days to a few weeks, and that requesting it does not guarantee inclusion in the results. It recommends a sitemap for large numbers of URLs, especially just after launching a site, and the URL Inspection tool for a few pages.
In a video on the Google Search Central channel, John Mueller explains that a new page can take up to several weeks to be indexed, and that in his view most good content is picked up within about a week. He lists what helps: a server that responds quickly, prominent links to new pages, and no thousands of useless URLs generated by filters or sorting.
In practice, on launch day I add the site and its sitemap to Search Console, check that the important pages are linked from the home page, then look at the indexing report the following week. If the blog is meant to grow afterwards, I automate publishing before producing more, so that putting content online does not become the new bottleneck.
06Where to start on Monday
If your date is set, take an hour on Monday to write three lists: the pages that must exist on launch day, the content with a name and a date for each piece, and everything that will wait for the next version. If the first list does not fit on one page, the timeline will not hold either.
Then name the person who decides and block out an hour a day for them over four weeks. The rest is building, and that is the most predictable part.
If you are starting from an existing site, my piece on migrating a website to Next.js and Sanity explains what changes. My services and a few past projects show how I work. If your schedule worries you, we can talk about it.