Case Notes

Ten Days Is a Sequencing Problem, Not a Speed One

A full replatform from proposal to live in ten days. Almost nothing was done faster than usual. What changed was the order.

By David Jube · Jul 26, 2026 · 7 min read

Table of Contents

A full ecommerce replatform went from proposal to live in ten days: a custom theme with no page builder, 183 products recategorised, 135 descriptions rewritten, 175 images reprocessed, a checkout repaired, and a host migration with a redirect map. The obvious question is how, and the obvious answer, that the work was done quickly, is wrong.

Almost none of it was faster than usual. What changed was the order, and specifically how early there was something real to react to.

Diagram showing workstream dependencies and key factors affecting project flow. — Days on which work reached a reviewable state. The overlap is the method; the compression is the result.

Key takeaways

Put a complete, ugly version of the whole thing in front of the client on day two, and every later day is spent reacting instead of guessing.
Sequence by dependency, not by importance. Work that blocks nothing can run in parallel with work that blocks everything.
The slowest part of most projects is waiting for a decision, so optimise for how quickly decisions can be asked for.

Standing up the whole site before finishing any of it

Two days after kickoff the entire site existed on password-protected staging. Not a homepage, not a template kit: every page, every template, the shop, a product page, the box builder, all rendering real data from the real catalogue. Most of it was rough and some of it was wrong.

That is the point. A rough complete site is a decision-making instrument. The client stops imagining and starts reacting, and reactions are specific in a way that briefs never are. The review queue that came back listed fourteen concrete requests about real pages, and eleven were applied before launch. None of those fourteen would have been discovered from a design mockup, because they were about how the real catalogue behaved inside the layout.

The alternative sequence, finishing the homepage to a polish and then moving to the next template, front-loads the work that is easiest to imagine and back-loads every unpleasant surprise. The surprises here were a merch range longer than the chocolate range, a checkout that was not configured, and product photographs that cropped badly in a square grid. All three were visible on day two and none would have surfaced in week three.

Running the workstreams that do not block each other

Once the shell existed, the remaining work split cleanly into things that depended on the templates and things that did not. Catalogue work was almost entirely independent: rewriting descriptions, reconciling nutrition labels and reprocessing images need the products, not the layout. Those ran alongside template work for a week rather than after it.

Configuration work was independent too. Shipping zones, payment mode and email delivery are properties of the store, not the theme, so they were repaired while the front end was still moving. The migration was the one genuinely serial piece, because a redirect map can only be finalised once the new URL structure has stopped changing.

Workstream	Depends on	Ran
Theme and templates	Kickoff decisions	Days 1 to 7
Catalogue and content	The product data only	Days 3 to 9, in parallel
Store configuration	Nothing in the rebuild	Days 5 to 9, in parallel
Client review rounds	A complete staging site	Days 8 to 11, overlapping
Migration and cutover	A settled URL structure	Days 9 to 11, serial

Read the dependency column rather than the dates. Three of the five workstreams depend on nothing that the other four produce, which means any sequence that ran them one after another was choosing to be slow.

The read

The causation tell is in where the calendar time actually went. Of the twenty-six days from the first diagnostic to launch, ten were the build. The other sixteen were the gap between delivering a diagnostic and the client deciding what to do about it, which is normal and is nobody’s fault.

Inside the build, no individual task was done at unusual speed. The descriptions took as long as descriptions take. What compressed the schedule was that the review cycle started on day two instead of day fifteen, and that three workstreams ran at once because nothing forced them into a queue.

The honest caveat is scope. This was a single-location retailer with one catalogue, no integrations beyond payments and shipping, and one decision maker who answered quickly. A business with three approval layers cannot compress the review cycle no matter how it sequences the work, because the constraint is not the building.

What this teaches

Ship a complete rough version before a polished partial one. Coverage surfaces the surprises; polish hides them until later.
Map every workstream to what it actually depends on. Most content and configuration work depends on data, not design, and can start immediately.
Treat the client review cycle as the critical path, because it usually is, and start it as early as something reviewable exists.
Expect the real surprises to be in the data. The unpleasant discoveries on this project were a bloated catalogue, a broken checkout and badly cropping photographs, none of them design problems.
Leave the genuinely serial work last and do not start it early. A redirect map built before the URLs settle is a redirect map built twice.
Be honest about what compression requires. One decision maker who answers within a day is a precondition, not a technique.

Frequently Asked Questions

How long does a website rebuild take?

It depends far more on decision speed than on build speed. This one took ten days from approval to launch for a small ecommerce site with one decision maker. The same scope inside an organisation with several approval layers commonly runs six to twelve weeks, with most of that spent waiting.

Should you build a website page by page or all at once?

Stand the whole thing up roughly, then refine. A complete rough site lets a client react to something real on day two, and it surfaces data problems early. Perfecting one page at a time front-loads the easy work and defers every unpleasant discovery.

What usually delays a website project?

Waiting for decisions and waiting for content, not the building. The most effective way to shorten a project is to give the client something concrete to respond to as early as possible, because specific reactions arrive far faster than answers to abstract questions.

Can content work start before the design is finished?

Yes, and it usually should. Product descriptions, metadata, image processing and store configuration depend on the underlying data rather than the layout. Running them in parallel with template work removes them from the critical path entirely.

What is the risk of a fast website rebuild?

Skipped verification. Speed is only safe when every bulk operation is reversible, the checkout is tested by simulating a transaction, and the redirect map is built from real search data. Compress the sequence, not the checks.

When should you build the redirect map in a migration?

Last, once the new URL structure has stopped changing, and from evidence rather than assumption. Build it from the old sitemap, a crawl for what the sitemap missed, and search-console history, so the map is driven by which URLs actually earned visits.

The takeaway in one line: compress the sequence, not the work, because the fastest project is the one where the client has something real to argue with on day two.

Wondering why your last site project took as long as it did? Mapping the actual critical path is part of a free diagnosis.

Continue Reading:

More From This Project

More from TDM Insights

Explore TDM Insights Topics