Weekly Demos

Demos of working software are the lifeblood of progress within software development. A text update can only convey so much information about progress. You need to see the progress and get feedback quickly—the tighter the feedback loop, the better. If you were trying to get better at dribbling a basketball, it wouldn’t help to write a text update of your progress and send it to your coach. You’d dribble the ball in front of them and get real-time feedback.

When I was working at my first agency, we had a simple practice for sharing progress with clients: Each Friday, we would send a short screencast talking through the progress we made that week. We’d show code, visuals, and any other relevant work. This practice allowed us to work against a consistent deadline, share work transparently, and build trust with clients.

In the book Creative Selection, Ken Kocienda describes a process called “creative selection” where the team would create a demo, receive specific feedback, and then produce another demo. This continuous demo → feedback → demo loop helped refine the best features and sparked new directions, all while keeping the team focused on delivering working software.

That is the power of weekly demos.

Deadlines

Constraints are critical to force trade-offs.

A weekly demo forces a deadline. Knowing you have to show your work in a week will force you to make specific decisions, keeping you from working on the wrong things.

In I, Ken Kocienda talks about the process of working on demos of the new iPhone keyboard. They had to create demos of an on-screen keyboard that never existed before, and present it to Steve Jobs. These deadlines forced them to make specific trade-offs and decisions.

Details

High-quality updates get into the details.

A weekly demo forces you to provide context and think out loud. It’s not a surface-level update. You’re showing what you built, how it works, and the thinking behind it.

I was recently listening to Farhan Thawar, VP and Head of Engineering at Shopify, on Lenny’s Podcast, and he talked about the value of pair programming in the same way. While it seems counter-intuitive for two engineers to work on the same thing at the same time, it’s not purely about the code they write. It’s about the shared understanding of the problem, the solution, and the details of the work.

A weekly demo has this effect, but as a reusable artifact. You can include it in documentation, send it to stakeholders, and reference it as needed while building the product. And imagine having that artifact created every week.

Decisions

Hundreds of decisions are being made every day when building software. The collective knowledge of the team grows directly proportional to the quality of shared context.

A weekly demo forces you to surface key decisions. When you have to think out loud and show your work, decisions naturally show up. This is the space where I like to work with the teams I’m leading. When we know what work to do, we’re dealing with knowns—these are straightforward. But the unknowns? That’s where collaboration and shared understanding matter deeply. Weekly demos highlight decisions and allow for more collaborators to provide input.

Show Working Software

Weekly demos create constraints through deadlines, force you to get into the right details, and surface key decisions. The best way to make progress is by actually showing your progress, to show working software.