Pieter Levels and Hoodmaps

The experiment

In 2017, Pieter Levels built Hoodmaps, a collaborative map for describing city areas, while livestreaming the work and posting progress publicly. His own account follows the project from the first line of code through a working prototype and a launch that reached Reddit's front page.

The useful lesson is not that every founder should livestream. It is that each public update contained visible evidence: a working map, drawings from early visitors, live technical problems, and the results of distribution.

What he made visible

Levels did not begin with a polished company narrative. He showed the problem, an old hand-drawn map that inspired the product, the prototype being assembled, and the first people drawing on it.

That sequence let an audience evaluate the work itself. The story followed the artifacts rather than replacing them.

What public building changed

The livestream created accountability and allowed viewers to help when he became stuck. Public progress also became part of distribution: people knew the project before the larger launch.

But his retrospective is equally clear about the cost. Keeping the service alive and managing attention required concentrated effort, including an unhealthy stretch without sleep. Visibility increased both support and operational pressure.

What beginners can borrow

Borrow the evidence

Show the current artifact and the problem it tests. You do not need the audience or production style of a livestream.

Borrow the sequence

Problem, prototype, early use, launch, and retrospective form a story naturally because they are real stages of the work.

Do not borrow the exhaustion

A dramatic public sprint is not a sustainable default. Define support limits before inviting a large response. Sleep and operational readiness are product constraints.

Acknowledge distribution advantages

Public building does not erase differences in audience, timing, reputation, or channel access. Study the mechanism without assuming the same reach.

Try the method at a smaller scale

1. Publish the problem and one artifact.
2. Build one working interaction.
3. Invite five relevant people to try it.
4. show what their behavior changed.
5. Launch the bounded version in one relevant community.
6. Publish an honest retrospective.

Levels documented the complete Hoodmaps process in his original build story and maintains a public list of projects that includes failures as well as successes.