Idea to Prototype

A two part workshop, ninety minutes each, and neither part is a lecture. Part one, Structure out of chaos, ends with a brief and a build guide. Part two, Build without fear, ends with something running at a URL. Each part has run twice, to more than thirty people, and the timings held up both times.

It is presented as one method, not the method, and the opening slide says so: things will break, do not memorise any of it, this is a safe space to try things that might not work.

The four phases

1. Stream everything. A brain dump with no structure, no editing and no judgment. Voice recording is encouraged, because talking is faster than typing. Nothing goes to a model yet.
2. Stream to structure. The dump goes into one prompt and comes back as a brief: problem statement, target users, one core user flow, three to seven features, success criteria, and what is explicitly not being built. Then you argue with the brief until it is small enough to be true.
3. Brief to guide. A second prompt turns the brief into eight to fifteen build prompts, in a fixed order: setup, features, polish, deploy.
4. Build, test, iterate. One prompt at a time, a preview after every one. Deploy whatever exists.

1. 01 A brain dump

   No structure, no editing and no judgment. Nothing has gone to a model yet.

2. Stream to Structure

   02 A brief

   Six parts, argued down until it is small enough to be true.

3. Brief to Guide

   03 A build guide

   Eight to fifteen prompts in a fixed order: setup, features, polish, deploy.

4. One prompt at a time

   04 Something running at a URL

   Deploy whatever exists, even if it is incomplete.

The prompts for phases two and three are in the workshop prompts.

The seven philosophies

Working first, beautiful later. One feature per prompt, each one testable before the next starts. Core before bells and whistles, hardcoded data before real data, proven tools over experimental ones unless the experiment is the point. They fold into a checklist that stays on screen while people build: a lens, not a gate.

How the room is designed

Pair work before solo work. A gut check alone, then you describe the idea to the person next to you and they ask questions. Anyone without one picks from nine ordinary annoyances, so nobody spends the session choosing.

Briefs are read aloud. Sixty seconds each, and the only feedback allowed is I'm confused about or what if you also.

Two tool paths. A browser builder by default, a local editor for the advanced track, and a build guide prompt for each.

A buddy and an escalation ladder. Everyone builds beside someone, and the rule is written down: stuck for more than ten minutes, escalate, do not dig deeper.

1. you

   1. 01Check the prompt
   2. 02Revert to the last working version
   3. 03Revise the prompt

2. the model

   1. 04Ask the model to fix it

3. your buddy

   1. 05Ask your buddy

4. the room

   1. 06Raise a hand

Red flags, listed. Authentication, more than one feature in a prompt, polish before the core works, a prompt where you cannot tell what to test. People check each other's build guides against the list before a single prompt runs.

Working beats finished. A broken prototype that runs beats a perfect one in your head, so the build opens with five minutes whose only goal is something on screen.

Broken demos are the best demos. Ninety seconds each: ten on the problem, sixty showing what works, twenty on one thing learned about the process.

The session continues after the room empties, in a channel where people post the live URL and one sentence about what they built.