How long a
website takes.

[Written by the Gleed studio · Last checked 31.08.2026]

1. [01]

   A range is not an answer

   Ask how long a website takes and you are usually given a range of weeks. A range is a forecast, and a forecast belongs to the person who made it: when it slips, it is revised, and the revision costs the studio nothing. Nobody is lying to you. They are answering a question about their own workload with the only figure they can be sure of, which is a wide one.

   The useful question is a different one. Not how long will it probably take, but what is the longest it can take, and what happens if that is exceeded. That second figure is a term rather than a hope, and it is the one you can plan a launch around.

   Every package here publishes one, beside its own scope, because a cap without the work it covers is a number nobody can check:

   • [Marker]Max 48H · one page
   • [Compass]Max 72H · up to 3 pages
   • [Atlas]Max 144H · up to 8 pages
   • [Meridian]Let's agree in chat :) · up to 15 pages

   Read those as four separate promises rather than one. The shortest one belongs to Marker at one page — it is not a speed the studio claims for everything it builds, and a studio quoting its fastest package at you for a job three times the size is doing the thing this page exists to warn about.

2. [02]

   What the clock counts

   A published duration is worth exactly as much as the definition of when it starts. Two studios can both say a week and mean a month apart, because one of them starts counting when you send the enquiry and the other when the scope is signed, the deposit has cleared and the content has arrived.

   Here it is written down: turnaround is counted from the moment we accept the brief, not from the moment you send it. Acceptance is a specific event — the price and the scope are fixed and the first instalment falls due — and it is shown on your own project page with the date it happened, so you never have to ask whether the clock is running. The whole rule is in the offer, in the clause about the clock.

   The clock also stops. Time the studio spends waiting on you — copy, photographs, an access code, an answer to a question, an approval — does not count against the cap. That is not a get-out clause; it is the only honest way to publish one. A studio that keeps counting while it waits has to pad the figure to survive the slowest client it has ever had, and you pay for that padding in the quote.

3. [03]

   Why one package publishes no cap at all

   Meridian does not have a number on this page and will not be given one. Its row publishes Scope fixed after paid discovery instead, because what it sells — a catalogue, payments, accounts, more than one language — is not a fixed quantity of work until somebody has established what you mean by each of those words. A date is fixed in the brief once that is done.

   This is the part of the answer most sites skip, and skipping it is how a launch date becomes an argument. A cap that is invented to avoid saying it depends is worse than no cap: it survives exactly until the first integration nobody scoped. Where a figure can be published it is published — 3 of the 4 rows carry one — and where it cannot, the row says so rather than rounding.

4. [04]

   What actually makes a build run late

   Almost never the code. In the order they cost real days:

   • Copy that does not exist yet. A design can be built around placeholder text; a launch cannot. The words for each page are the single most common thing a client has not started when they expected to be live.
   • An approval with no owner. If three people have to like it and none of them has the final word, the revision round does not end. Naming one person who signs off is worth more to your date than any process a studio can put in place.
   • Access nobody has to hand. The domain was registered by somebody who has left, the login goes to an inbox that closed, the registrar wants a transfer code and takes days to send it. This is the one delay that can be longer than the build.
   • A third party on its own schedule. A payment processor verifying a business, a booking system with a queue, a supplier who has to export a product list. None of them care about your launch week.
   • Scope that grew after signing. One more page, one more language, one more form. It is allowed and it is quoted before it starts — it is simply not free, and it moves the date it was added to.

   Four of those five are yours rather than the studio’s, which is why the list of what we need from you is published before you pay for anything rather than sent as a surprise on day two.

5. [05]

   Buying a place in the queue

   A cap can be bought down. Double priority costs 30% on top of the package price and halves the cap that package publishes. What it buys is a position: the build takes the next free slot ahead of standard work.

   What it does not buy is a different way of working. The page count, the revision rounds and the signed scope are exactly the ones you would have had at the standard price — a queue price, not a speed promise. Nobody skips a step, and if a studio offers you a rush fee that shortens the work rather than the wait, ask which step is being dropped.

6. [06]

   Four questions to ask any studio

   These work on us and on everybody else, and the answers tell you more than a portfolio does.

   • Is that an average or a maximum? If the answer is an average, ask what happens on the bad half of it.
   • What event starts the clock? The signature, the deposit, the content arriving, or the first email. All four are used, and they are weeks apart.
   • What happens to the date if I am slow? A studio that has never thought about this has never had a client who was.
   • Is the date in the quote? A turnaround that appears only in the sales conversation is a turnaround nobody has agreed to.

   Ours are all answered on one screen: the pricing page prints each cap beside the scope and the price it belongs to, and the offer is the document that holds us to it.