Ship Software in Weeks, Not Months: The Weekly-Demo Cadence
Working software by week two is not a stunt. It is a discipline: scope a thin first slice, demo every Friday, and let real usage steer the build before the budget runs out.
The thesis: feedback cadence beats specification
Most custom software fails slowly. A long spec is signed, months pass, and the first working version lands after the requirements have already drifted. The fix is not a better spec. It is a shorter feedback loop.
Our cadence is simple: working software in the user's hands by week two, a live demo every Friday, and typical builds landing in four to six weeks. Each demo converts an assumption into evidence. The plan is allowed to change because the people using the thing are in the room while it is still cheap to change.
This only works with senior engineers who can scope, build, and talk to a client in the same week. Hand-offs between a separate analyst, builder, and tester reintroduce the lag you were trying to kill.
Scoping the first thin slice
A thin slice is the smallest end-to-end path that a real user can actually run, not a mockup and not a backend with no screen. It should touch the spine of the system once so the hard integration risks surface early.
For a sales-pipeline CRM replacing a shared Excel register, a sensible first slice would be: sign in, create a lead, move it through its configurable stages, and see it persist for the whole team. That alone proves auth, the data model, and the stage workflow, which is most of the technical risk.
Pick the slice that retires risk, not the slice that looks impressive. If single sign-on or a third-party integration is the scary part, put a working version of it in week one, even if it is ugly.
- End-to-end and usable by a real person, not a stub or a screenshot
- Touches the riskiest integration first (SSO, statutory rules, document control)
- Small enough to demo Friday and revise the following week
- Deliberately excludes edge cases until the spine is proven
The Friday-demo loop
Every Friday you show running software against the real environment, not slides. The client clicks through it, reacts, and reprioritises the next week's work on the spot. Decisions that would sit in an email thread for days get made in the meeting.
The loop has three moves. Show what shipped this week. Watch where the user hesitates or pushes back. Agree the single most valuable thing to build next. Written notes from each demo become the living backlog, replacing the frozen spec.
Because the increment is one week, a wrong turn costs one week. That is the whole economic argument: small bets, fast correction, no six-month surprise.
What makes it succeed or fail
It succeeds when the client sends one empowered decision-maker to every demo, when scope stays narrow per week, and when the team ships something real even on a hard week. Momentum is the product; a demo with nothing new breaks trust faster than a bug.
It fails on the predictable things. Scope that balloons mid-week. A slice chosen for looks over risk, so integrations blow up in week five. Approval chains where no one in the room can actually decide. And demos faked with mockups, which only defer the reckoning.
- Succeeds: empowered client owner, narrow weekly scope, always-shippable increments
- Fails: scope creep, demo-driven theatre, deferred integration risk
- Fails: no decision-maker present, so the backlog never gets reprioritised
Why the cadence holds across very different builds
The same loop carried a Section 138 cheque-bounce case manager for a manufacturing distributor, where statutory deadlines under the Negotiable Instruments Act 1881 are auto-computed and wired into Power Automate, shipped in six weeks. It also carried a multi-office law-firm ERP, with matter management, billable hours, a four-step invoice approval on Power Automate, GST-ready invoicing, SharePoint document control, and a Copilot Studio bot grounded on the firm's own data, shipped in nine weeks.
The domains share nothing. The cadence is what travels. One recommendation that does travel: for anything legal or financial, design the audit trail to be append-only from day one, so history can never be quietly rewritten. Decide that in week one, not after go-live.
Don't write a longer spec; shorten the feedback loop. Scope a thin first slice that retires your biggest integration risk, get it usable by week two, and demo running software every Friday so a wrong turn costs one week instead of six months.
Frequently asked
How can you have working software in two weeks on a custom build?
By scoping a thin first slice, the smallest end-to-end path a real user can run, rather than building the whole system at once. The first slice proves auth, the data model, and the riskiest integration. Everything else is layered on in later weekly increments, each shown at a Friday demo.
What happens at the Friday demo?
We show running software against the real environment, the client clicks through it and reacts, and together we agree the single most valuable thing to build next. Notes from each demo become the living backlog. Because each increment is one week, a wrong turn only costs a week to correct.
Why do some ship-in-weeks projects still fail?
They fail on scope creep mid-week, choosing a flashy first slice instead of the riskiest one so integrations break late, no empowered decision-maker in the demo, or demos faked with mockups. The cadence only works when the client sends someone who can decide and each weekly increment is genuinely shippable.