Ten days to a working build. The actual calendar.

People ask how we get to a working build in ten days. The honest answer is that one senior person owns the whole thing, and the room is small enough to decide.

Here's the calendar we actually run. It hasn't changed much in a year, because the shape of the problem doesn't change much either.

Days 1 to 2: access and decisions

Three questions, answered in writing, with the people who can say yes. Who uses this? What data can we touch, and where does it live? What does good look like on day ten?

This is the boring part. It is also the reason most projects take six months: nobody asked these questions until week four, when the answers turned out to be inconvenient. We ask them first, and we don't start building until we have them. Access to a real system, even read-only, is the one non-negotiable. A pilot without access is a slideshow.

Days 3 to 5: one thing, end to end

Not the whole product. One workflow, end to end, on real infrastructure, touching real data. If the product is a booking agent, day five is one kind of booking, from message to confirmation, for real. It can look rough, but it has to be real.

The temptation here's to widen. Three workflows instead of one, a dashboard nobody asked for, a settings page. We hold the line, because everything we add now is something real users can't break on day six.

Days 6 to 8: real users, real data, real bugs

A handful of the client's own people use it. It breaks in ways a workshop would never have predicted. The retrieval falls over on a document format nobody mentioned. A user types in a mix of Arabic and English and the agent gets confused. Somebody tries to book a slot that doesn't exist.

This is where the product actually gets designed. Every bug is a decision we would otherwise have made by guessing. We fix them the same day, and the next morning the same users try again.

Days 9 to 10: demo, harden, decide

We show it working to the people who weren't in the room, and we record it so the people who couldn't make that meeting can see it too. We harden the parts people loved and remove the parts nobody touched.

Then we decide together. Go, change course, or stop. All three are fine outcomes. The point is that you decide with something real in your hands.

When one senior person owns the whole thing and the room is small enough to decide, ten days is plenty.

What you hold on day ten

A working build on your systems. A one-page scope. A fixed price and a go-live date for the road to production. A recording of the demo. And a decision that's yours to make.

After that, the rules change to the ones that make a product stick: fixed scope, fixed date, one owner on each side, and tests before every release. The whole process is on one page.