How to launch a website in 72 hours (without shortcuts you pay for later)
Launching a website in 72 hours is neither magic nor a marketing trick. It is the result of making every hard decision before you write the first line of code, and cutting the work that does not move the needle.
Most projects do not take months because they are technically complex. They take months because the scope shifts every week, because assets are missing, and because every small decision spawns a new meeting. Remove those three sources of delay and three days stops being absurd.
The secret is not going fast, it is never stopping
A team that knows what it has to build does not need to rush. It just needs to not stop. So the right question is not "how do we go faster?" but "what is going to slow us down, and how do we remove it before we start?".
1. Lock the scope before day one
We define a single page, or a fixed set of pages, the exact sections, and what goes into each one. Anything not on that list is not built in this sprint. Full stop. This is not rigidity: it is what lets us promise a date.
2. Gather the assets up front
Copy, logos, photos, access to the domain and email. If we wait to ask for each thing when we need it, the clock stops. An asset list delivered on day one is worth more than any code optimisation.
3. Design with a system, not from scratch
We build on proven components —typography, buttons, cards, forms— instead of inventing every element. The result looks bespoke because the brand and content are, but the foundation is already solved.
The real timeline
- Day 1 — Definition and structure. Lock sections, hierarchy and copy. Stand up the navigable skeleton.
- Day 2 — Design and content. Apply brand, imagery and final copy. Live review, not over email.
- Day 3 — Polish and publish. Responsive, performance, basic SEO, connected forms, and the domain in production.
What does not fit in 72 hours
Be honest with the client: an e-commerce store with 500 products, custom integrations, or a complex admin panel do not fit in three days. And that is fine. The 72-hour website is for validating, capturing leads and getting moving; the rest is a separate sprint with its own scope.
A published, improvable website always beats a perfect one still sitting in Figma six weeks later.
If you have the assets ready and the scope clear, three days is plenty. The bottleneck is almost never the code: it is the decisions that were not made in time.
← Back to the blog