Skip to content
Díaz Oliva
Back to blog

How it works

How long a website takes (and why it runs late)

· 4 min read ·

How a website project's calendar is spent: 70 % waiting for content and 8 % building
Building is the short part, and the most predictable.

"When would I have it?" is the second question in almost every first conversation, right after the price. The honest answer is slightly uncomfortable, because the timeline does not depend solely on whoever builds the website.

Here the timeline is yours

It is worth saying up front, because it changes the whole question: at Díaz Oliva there is no delivery time to wait for. The site is built in the editor as you type and it is published when its owner decides. There is no queue, no diary slot to free up, and no first version arriving in a few days.

What there is instead is a free entry plan you can publish with, and fees for whatever needs more than that plan includes. Building and trying it costs nothing.

That said, the question is still a good one, because the time goes somewhere else.

If someone promises a complete corporate website in 48 hours, they are promising a template with a logo on top. That is a legitimate option, but it is worth knowing what is being bought.

Where the time genuinely goes

Putting the pages together is the short and predictable part. What eats the calendar is almost always the rest of it.

Gathering the content: between 60% and 80%. That is not an exaggeration. A site that could have been done in two afternoons ends up taking two months because the service descriptions, the photos of the premises or the logo in a usable format are missing. The structure was settled on day one.

Postponed decisions. If it is still undecided whether prices are published, or whether appointment booking is needed, work stops at that point. Not for lack of hands, but because whichever path is taken will have to be undone afterwards.

Access and admin. The domain registered by someone unreachable, access to the panel where it is managed, the payment gateway account if there is a shop. These are delays that do not depend on whoever builds the site, and they surface right at the end, when everything else is done.

Polishing what was already fine. Changing the headline for the fifteenth time does not bring publication any closer. Once a page says what it needs to say, carrying on tweaking it is time that reaches no visitor at all, because meanwhile the site is still unpublished.

Putting the pages together: considerably less than people assume. With the content in front of you and the decisions made, a correct, accessible, fast corporate site takes an afternoon.

How it works here

The studio's approach is built around precisely that bottleneck. There is no calendar slot to wait for and no first version to be sent over: you answer eight questions or start from a template, and five minutes later there is a complete, navigable website rather than a mockup, and it opens on a phone.

From there the clock sits where it has always sat, except that now it is held by the person who has the content. Changing a headline means typing it and watching it change alongside, so the wait between "I don't like this" and "done" disappears. What still takes as long as it takes is gathering the words and the photographs.

What speeds nothing up

Waiting until you have everything. A published site with four good pages is working today; a twelve-page one still unpublished next month is not working at all. The missing pages get added later, and adding them means writing them.

Starting with the colours. Choosing the palette before knowing what the home page says is furnishing a house before knowing how many rooms it has. Colour and typeface change in two clicks once the text is there; the other way round, every edit to the text means checking all over again whether it still looks right.

Asking too many people what they think. When observations arrive from five people who have not agreed among themselves, the site stops moving forward and turns into arbitration. Better that one person decides and that the debates happen beforehand.

What genuinely shortens it

Gather the content before you sit down to build, not after. This cuts the calendar more than anything else, by a distance. Text, photos, logo and legal details to hand turn two weeks into an afternoon.

Start from a template or from the short questionnaire. A blank page is the slowest way to arrive anywhere. With the structure already in place the work becomes replacing sample text with your own, which is a task you can watch advance.

Write first, compose afterwards. A section drops into place in a moment once you know what it says; deciding the layout of text that does not exist yet is guesswork.

Sort the domain on day one. Checking who the registrant is and who has panel access costs ten minutes at the start and can cost three weeks at the end.

Publish before it is perfect. Publishing closes nothing off: the site carries on being edited afterwards, and every change shows up straight away. What you do not get back are the weeks it sat finished with nobody able to see it.

In short

A website's timeline is no longer set by somebody else. Putting the pages together is an afternoon's work and there is no queue in front of it. What takes as long as it takes is gathering what only you have: what your business does, how it differs and which photographs show it.

So when something stalls, the useful question is rarely "when will it be ready?" but "what exactly is missing?".

And checking that costs very little: you start here, the site shows up as you type, and publishing it costs nothing.

Share

Shall we build it?

You build it here, you see it as you go, and you publish it without paying: the entry plan is free.