01Where the weeks actually go
If you have ever wondered why a five-page site takes two months, the answer is that almost none of it is building. Count the actual working days spent writing code on a small business site and you will usually land somewhere between two and five. The rest is queue time: waiting for the brief, waiting for the proposal to be read, waiting for a decision from someone who was not in the meeting, waiting for photos. Queue time is invisible on an invoice, which is why nobody itemises it, and it is also the only part that can be removed without removing craft.
- Waiting for the brief, which most business owners have no time to write.
- Discovery calls, which mostly recover what the brief was supposed to say.
- A proposal, then waiting for it to be read and signed.
- Design mockups, then a round of feedback, then another.
- Waiting on your content, which is where most projects genuinely stall.
- Actual building, which is usually the shortest part.
02What genuinely cannot be rushed
Speed comes from removing waste, not from removing work, and it is worth being precise about which is which. A discovery call that recovers information a one-line brief already contained is waste. Photographing a restaurant's actual dishes is not. Anyone who tells you a full online store ships in two days is either redefining the word store or planning to hand you something they will quietly finish afterwards. The honest version of a fast timeline names what it excludes, out loud, before you agree to it.
- Photography that does not exist yet. Nobody can build around photos you have not taken.
- A store with a real product catalogue, stock and tax rules.
- Anything needing legal or medical review before publication.
- More than two languages, where every change multiplies.
- Migrating a large site without losing its search positions.
03How to make any project go faster
Whoever builds your site, four things cut weeks off the timeline and cost you nothing. They all come down to removing decisions from the critical path. A reference link removes an entire round of interpretation. One named decision-maker removes the week where two people disagree politely by email. Gathering your service list and photos before you are asked removes the stall that kills more projects than any technical problem. And accepting that version one is not final removes the longest delay of all, which is waiting for a perfect page that nobody has started writing.
- Send a reference site you like instead of describing what you want in words.
- Decide who has final say before you start, and make it one person.
- Gather your photos and your service list first, not when asked.
- Accept that version one does not have to be final. A live site you improve beats a perfect one that never ships.
Where the time went on a rebuild we actually did
SCP Shine & Style already had a website. Rebuilding the pages was the fast part. What took real time was everything around it: exporting the old URL list so nothing indexed would break, writing a page per service instead of one page listing thirty, and shooting and declaring 21 video clips so Search Console would count them. None of that is visible on the finished site, and all of it is why an honest timeline separates the build from the migration.
See the build: SCP Shine & StyleWhere PROOF48 fits
PROOF48 delivers a business website in 48 hours because the brief is one link and there is no proposal to approve. Stores and web apps get their own timeline, which we tell you when you send the link rather than after you have paid.
Cosmin Tiu · Founder, PROOF48
Cosmin has worked in online marketing and software development since 2018, and has built with AI every day since January 2023. He still writes code from scratch daily, in Python, React, Rust and C#. PROOF48 ships business websites in 48 hours and invoices afterwards, so every opinion on this blog was paid for in real builds, not in theory.