Shipping in two weeks: what it really takes

A two-week build sounds aggressive until you have done a few. The constraint is not speed — it is scope discipline. Two weeks is enough to ship something real if, and only if, you refuse to let the scope drift. Here is how we hold the line.

One outcome, written down before day one

Every two-week build has exactly one sentence describing what will be true at the end. Not a feature list — an outcome. “Ops can approve refunds without touching the spreadsheet” is an outcome. Everything that does not serve that sentence is out, and we agree that in writing before we start.

Cut vertically, not horizontally

The temptation is to build every screen halfway. The discipline is to build one path all the way through — real data in, real result out — and only then widen it. A thin slice that actually works beats a broad demo that does not, every time.

• Days 1–2: confirm the outcome, model the data, wire the riskiest integration first.
• Days 3–7: build the single happy path end to end with real data.
• Days 8–11: handle the edge cases that actually occur, not the hypothetical ones.
• Days 12–14: harden, hand over, and document how to run it.

Do the scary part first

Whatever you are least sure of — a flaky third-party API, a messy data source, an unproven AI step — gets built on day one, not day ten. If it is going to break the timeline, you want to know while there is still time to change course, not the night before delivery.

You cannot compress a two-month project into two weeks. You can deliver the two weeks of it that actually matter.

The deadline is the feature

Because we do not get paid if we miss the date, the deadline shapes every decision — what to build, what to cut, and what to flag early. That pressure is not a burden; it is the thing that keeps the work honest and shippable.