A six-month build and an eight-week build usually contain a similar amount of code. The difference is what surrounds the code: the deciding, the waiting, the re-deciding, and the work done twice because the first version was built before anyone had seen it.
Where the months actually go
On the projects we inherit mid-flight, the pattern is consistent. The time is not in implementation:
- Deciding. Weeks spent choosing between options that are, in practice, equivalent for the workload in question.
- Waiting. Access, credentials, a sample data export, a stakeholder review scheduled eleven days out.
- Speculative generality. Building a plugin architecture for the second integration that never arrives.
- Late feedback. The first demo lands in month four, and reveals the workflow was misunderstood in week two.
None of these are fixed by working harder. They are fixed by changing the shape of the project.
The four things we cut
1. Breadth, until one workflow is finished
The first release covers one complete workflow end to end, for real users, with real data. Not five workflows at 60%. A warehouse system ships receiving before it ships cycle counts, returns, or reporting. A partial workflow is worth nothing; a complete one starts paying immediately and — more importantly — starts generating accurate feedback.
2. Bespoke infrastructure
Managed Postgres, managed auth, managed file storage, a platform that deploys on push. Every hour spent on a cluster is an hour not spent on the thing the client is paying for. We revisit this only when scale or a compliance requirement genuinely forces it, which for most business systems is never.
3. Design systems built from scratch
Start from a mature component library and restyle it. Custom components are written when a real interaction demands one, not pre-emptively for a palette.
4. Meetings that are not decisions
One standing review per week with someone empowered to say yes. Everything else is asynchronous and written. A decision that waits for a scheduled meeting costs days; the same decision made in a thread costs an hour.
Scope is the only variable that reliably moves a deadline. Adding people to a late project is the oldest failure in the field.
The five we never cut
This is the part that separates fast from reckless. These take days, not weeks, and skipping them converts a delivery into a liability.
- Real authentication and authorisation. Roles and tenant isolation enforced in the data layer from the first migration. Retrofitting authorisation into a live system is close to a rewrite.
- Migrations under version control. Every schema change is a file, reviewed and replayable. Hand-edited production schemas are how environments diverge and stay diverged.
- Backups with a tested restore. An untested backup is a belief, not a backup. We restore into a scratch environment before go-live.
- Error tracking and structured logs. Shipped on day one. Without it, the first production bug is investigated by asking the user what they clicked.
- Tests on money, stock, and permissions. Not blanket coverage — targeted tests on the logic where being wrong is expensive and silent.
What eight weeks actually looks like
| Phase | Duration | Output |
|---|---|---|
| Workflow mapping | Week 1 | The chosen workflow drawn step by step, with the data each step reads and writes. Signed off. |
| Schema & access | Week 1–2 | Migrations, tenancy model, roles, RLS policies, seed data, environments live. |
| Vertical slice | Week 2–3 | One screen writing real rows through real permissions. Demoed. |
| Build out | Week 3–6 | Remaining screens, integrations, imports. Weekly demo on production data. |
| Hardening | Week 6–7 | Edge cases, restore test, load sanity check, observability review. |
| Pilot | Week 7–8 | Real users on real work, daily fixes, then cutover. |
The demo in week three is the mechanism that makes the rest work. It is where you discover that the workflow you mapped is not the workflow people actually follow — early enough that correcting it costs days rather than a rebuild.
When this is the wrong model
It would be dishonest to present this as universal. Eight weeks is the wrong plan when:
- The domain is genuinely novel and requires research, not construction.
- Regulatory certification gates the release, and the calendar belongs to the certifier.
- A legacy migration carries a decade of undocumented behaviour that has to be reverse-engineered before anything can be replaced.
- No one on the client side can make decisions within a day.
The last one is the most common, and the most fatal. Delivery speed is a shared property of both teams. We can compress everything on our side of the line; a decision that takes two weeks to make still takes two weeks.