The Art of Ecom · Jimmy, Partner & Manager
Delivery cut from 30 days to 5.
An e-commerce agency ships in five days what used to take a month. The scope did not shrink and the checklist did not get shorter. What went away was the part of the month where nothing was happening.
- Delivery time
- 30 days to 5
- Scale
- $300k months
- Business
- E-commerce agency
A month of delivery is rarely a month of work
Take any project that runs four weeks and add up the hours somebody actually spent on it. The number is small. The rest of the calendar is a stage that is finished sitting in front of a stage that has not started, because the person who owns the next step has not noticed yet that it is their turn.
The waiting is not one long block either, which is why it is hard to see. It is a file that arrives in the wrong format on Tuesday and gets fixed on Thursday. It is an approval that takes four minutes to give and six days to reach the top of somebody's inbox. It is a question that could have been answered on day one and gets asked on day nine, because that is when the work reached the point where it mattered.
Every extra handoff adds another one of those pauses, and the pauses compound. That is why adding people to a project of this shape often makes it slower rather than faster. More people means more edges, and the delay lives on the edges, not inside the work.
It also decides how much a business can carry. If a project holds a slot for four weeks and the work inside it takes days, the calendar is booked with waiting. New work queues behind projects that are technically idle, and the only visible fix looks like hiring.
- The brief is answered in an hour, once somebody sits down to answer it, and that sitting down takes eight days.
- Assets arrive incomplete, and nobody finds out until the stage that needs them starts.
- A stage is finished on Wednesday and picked up the following Monday, because that is when the next person looked.
- Review turns into a rewrite, so a check that should take an hour reopens work that was done.
- The same question gets asked three times, in three threads, because the first answer was never written anywhere durable.
- A project blocks a slot in the calendar for weeks while nobody is working on it.
What the system does with a delivery
We build the delivery as a run instead of a sequence of favours. The run has fixed inputs, fixed stages and a fixed checklist, it starts the next stage itself the moment the one before it is done, and it holds anything it cannot answer from the approved material rather than filling the gap. The steps below are the general shape of that, not a report on any one client's internals.
- 01
Fix the inputs before the run starts
Every recurring delivery needs the same handful of things: the brand material, the product data, the approved offer and pricing, the copy that has been signed off. Those become named inputs with a state. The run reads them from one place, so nobody chases the current version and nobody works from a file that was superseded on Friday.
- 02
Ask everything that will be needed on day one
The questions that stall a project on day nine are knowable on day one. They get asked in one pass, at the start, in the form the work will actually need. What comes back is stored as a source the later stages read from, not as a message in a thread that has to be found again.
- 03
Turn the delivery into named stages
Brief, data, copy, build, checks, handover. Each stage has an entry condition, a defined output and a checklist that is the same for every client. Repetition is where the speed comes from. The stages are not shortened, they are made identical, which is what lets them start without a conversation about how this one works.
- 04
Let each stage start on the one before it
A finished stage triggers the next one. Nothing waits for somebody to notice, to check a board, or to be reminded in a standup. This is the single change that removes most of the calendar, because most of the calendar was the gap between done and noticed.
- 05
Make review a check and not a rewrite
The work is produced against the standards it will be judged by, so review compares output to a list instead of forming an opinion. Anything that fails the list goes back with the specific item named. A reviewer who has to rewrite is a sign that the standard was never written down, so we write it down first.
- 06
Keep the trail from output back to input
Every delivered item records which input it came from. When something needs correcting, the correction is one step: change the source, rerun the part that used it. Without that trail, a small change becomes a search through the whole delivery, and the search costs more than the change.
- 07
Stop where the answer is not on the approved sheet
If a price, a term or a claim is not in the material that was signed off, the run does not infer it from something similar. It holds that item, flags it, and puts it in front of a person with the question stated plainly. The rest of the delivery keeps moving. Guessing on the money line is the one failure that would cost more than the month we saved.
- 08
Hand over a package, not a status update
The run ends with the deliverable, the checks that were run, and what a human still has to decide. The client gets a thing they can use, and the team gets a delivery that closed itself rather than one that needs a meeting to declare finished.
What changed
Delivery went from 30 days to 5. The scope of what gets shipped is the same and the checklist behind it is the same, which is the only reason the number means anything. What disappeared was the waiting between stages, not steps that used to be done and now are not.
That is the sentence worth taking from this page: the time saved was waiting time, not work. Nobody worked faster and nobody worked longer. The stages stopped queuing behind each other, so the calendar stopped holding a slot open for a project that was idle.
The knock-on effect is capacity. When a delivery occupies days instead of weeks, the next one starts sooner without anyone being hired, and a business at $300k months is running that throughput on the same team rather than on more of them.
- Delivery cut from 30 days to 5, at the same scope.
- $300k months, with the delivery running as a repeatable run.
- The saved time came out of the gaps between stages, not out of the work.
- The next project starts when the run ends, not when somebody frees up.
What this case does not claim
This case shows one thing: a recurring delivery that used to take a month now takes five days, with the same scope and the same checks. It does not show less care. Speed here comes from removing waiting and repeating a fixed process, not from cutting steps, and a run that skipped its checks would have been faster and worse.
The number belongs to this kind of delivery, in this kind of business: work that repeats with a known shape and known inputs. It is not a rate we apply to every project, and one-off work that has to be figured out as it goes will not behave like this. We say which parts of a business look like this before we build anything, including when the answer is that most of it does not.
Frequently asked questions
How do you shorten a project timeline without cutting scope?
You take the time out of the gaps rather than out of the work. In most projects the hours actually spent are a small share of the elapsed calendar, and the rest is a finished stage waiting for the next person to notice. When each stage starts on the one before it, and the questions that would have stalled it were asked at the start, the same work fits into a fraction of the days. Nothing is removed from the deliverable, which is the only version of this worth having.
Why do agency projects take so much longer than the work inside them?
Because a project is a chain of handoffs, and every handoff has a pause in it. A file arrives in the wrong format, an approval sits in an inbox, a question surfaces at the point in the work where it matters instead of at the start. Each pause is small and forgivable, and there are twenty of them. That is also why adding people can make it slower: more people means more edges, and the delay lives on the edges.
Can we deliver faster without hiring more people?
Usually yes, if the delivery repeats. Extra headcount buys more parallel work, but the constraint in a repeating delivery is normally waiting, not capacity, and hiring does not remove waiting. Fixing the inputs, making the stages identical and letting each one trigger the next frees the calendar without changing the team. If the real constraint turns out to be capacity, we say so rather than selling a system that will not help.
Does an automated delivery mean less quality control?
It means the opposite, if it is built properly. The checklist has to be written down before anything can run against it, and once it is written down it runs every time instead of on the days someone has the attention for it. Review becomes a comparison against a stated standard rather than a reviewer forming a fresh opinion under time pressure. The failure mode we design against is not slow review, it is unwritten standards.
What happens when the system does not have the information it needs?
It stops on that item and asks a person. A price, a term or a claim that is not in the approved material is never inferred from something that looks similar. The item is held and flagged with the question stated plainly, and the rest of the delivery continues around it. A run that guesses on the commercial detail would undo the value of running at all.
Which kinds of work does this fit?
Work that repeats with a known shape: the same type of deliverable, the same inputs, the same checks, done again for the next client. That is where a fixed run pays for itself, because the process is written once and used many times. Work that is genuinely new each time will not compress the same way, and we would rather tell you that before a build than after one.
How long does it take before a delivery runs like this?
The first useful version comes from one delivery type rather than the whole business, so it is a matter of weeks and not a transformation programme. The first step is mapping where the current calendar actually goes: which stages wait, on whom, and for how long. That map usually shows a small number of handoffs carrying most of the delay, and those are what get built first.
Bring us the delivery you run most often
Take the project type you sell every month and write down where its calendar goes: the days of work, and the days of waiting between them. If the second number is the larger one, that gap is the project. Apply, show us the delivery and its steps, and we will tell you honestly how much of it is waiting and whether it is worth building.
Apply