The calendar invite went out Monday at 9 a.m., before a single line of code existed: "Friday, 4 p.m., conference room B. Maria from dispatch will drive." No agenda, no deck, just a room that will contain actual users at a fixed time, and the quiet understanding that something working had better be on the screen.
Nothing I have tried in fifteen years of shipping software focuses a week of building like that invite. Not story points, not sprint goals, not the burndown chart somebody updates on Thursdays with theatrical guilt.
Demo driven development is the practice of scheduling the demo first and letting it shape everything after. You pick a recurring slot with real users, show working software on real data every week, let the users do the clicking, and turn fifteen minutes of their notes into next week's scope. It's not a ceremony. It's a forcing function.
The Friday 4 p.m. forcing function
A deadline with an audience behaves differently from a deadline without one. "End of sprint" is negotiable; you can carry a ticket, re-estimate it, or explain it. Maria sitting in conference room B at 4 p.m. on Friday is not negotiable. She drove over. She brought the operations manager.
That pressure works upstream. On Monday, nobody asks "what should we build?" They ask "what will we show?" The difference sounds small and changes everything: scope gets cut to what can be demonstrated, edge cases get postponed in favor of the main path, and every hour of work has to justify itself against the question of whether it will be visible at 4 p.m. Friday.
It also kills the status meeting. When the demo is the status, nobody needs a slide about the status.
What demo driven development actually is
Strip it to the studs. Demo driven development means the demo is scheduled before the work, attended by real users, performed on real data, and run by the users' hands rather than the developer's. The feedback from each demo sets the next cycle's scope, in writing, within a day. Call it demo driven development because the demo drives; everything else is commentary.
It is not a sprint review, where the team presents finished tickets to stakeholders who approved those tickets three weeks ago. It's closer to a standing appointment with reality. The software doesn't have to be done; it has to be showable, which turns out to be a much more honest standard.
The week shaped like a demo
Monday is the scope-cut. The question on the table is "what will Maria click through on Friday?" not "what can we theoretically finish?" Anything that can't be shown isn't in the week, no matter how important it feels. Important-but-invisible work gets scheduled openly instead of smuggled in.
Tuesday through Thursday, the build runs backward from the demo script. You write the three-minute walkthrough first: Maria opens the queue, reassigns a job, watches the route update. Then you build exactly that path. It rhymes with the rapid prototyping playbook, where the prototype's job is to earn the next conversation rather than to be complete.
Friday is the show plus fifteen minutes of brutal notes. Brutal is the operative word. "It's nice" is useless; "I would never click that because the truck number isn't visible" is gold. Those notes, cleaned up on Monday morning, are the scope. The loop closes itself.
A concrete week, say for a dispatch queue tool. Monday: the team decides Maria will open the queue, reassign one job, and watch the route update — three clicks, nothing else. Tuesday someone notices the permissions model isn't built; it goes on the not-this-week list, because the demo doesn't touch it. Wednesday a real export from their system replaces the sample data, because fake data got called out last week. Thursday is rough, as Thursdays are, but the path works by 7 p.m. Friday, 4:12 p.m.: Maria reassigns a job, and her first note is that she wants the driver's phone number on the same screen. That's next Monday's scope, and nobody had to guess.
Rules that keep it honest
The cadence rots fast without rules, so we keep five. Demo on real data or say out loud that it's fake — one unlabeled fake dataset and users stop trusting everything they see. The user clicks, not the developer; a demo the developer drives is a presentation, and presentations lie.
No "imagine this button worked." If it isn't wired, it isn't shown. Tangents go to a parking lot that gets read out loud at the end, so nobody's concern evaporates but the demo doesn't derail. And you get to cancel a demo for having nothing to show exactly once. The second cancellation means the cadence is broken and you fix the cadence, not the calendar.
One more rule that's really a courtesy: keep it under twenty minutes. Attention is the currency you're spending, and the demo that respects the clock gets invited back next week.
What the demo kills
Gold-plating dies first. A feature can't survive a weekly audience of actual users if it doesn't help them, which is why demo-driven teams accumulate less ornamental software than sprint-driven ones. Architecture astronautics dies second: nobody wants to explain to Maria that this week was spent making the system "more extensible."
My favorite execution happened at minute four of a demo for a regional distributor. We'd spent two days on a clever bulk-editing grid. The ops lead watched someone use it once, shrugged, and said, "we'd never trust that — we need to approve each one." Two days of work, gone, and a month of planned enhancements to the grid went with it. That sounds like a loss. It was a bargain: the sprint-shaped version of that story ends with the month spent, then the shrug.
This is the same discipline behind shipping in days instead of months: small surface area, constant contact with the person who'll use the thing, and no room for the work to drift away from the need.
Adopting it without an FDE in the room
You don't need an embedded engineer to steal this. You need one user with real work and real opinions, a recurring slot they actually attend, and the nerve to show unfinished software. Start with the two-demo rule for new stakeholders: they watch one demo before they get input privileges, because feedback from people who haven't seen the current state is how roadmaps get weird.
The standard objection is "it's not ready." Right — that's the point. Ready is a feeling that arrives about two weeks after the users needed to see it. If your team is also wrestling with how much to build before showing anyone, the exercise in cutting MVP scope to what actually matters pairs well with a Friday deadline.
Send the invite before you feel prepared. Book the room, name the user, and let the week organize itself around 4 p.m. Friday. The software that gets shown is the software that gets used, and the software that gets used is the only kind that was ever worth building.