Why prototypes deserve their own folder.
Most of what a working developer learns happens in the gap between two production projects. The thing that fits in that gap is a prototype. A focused build, scoped tight, shipped to localhost or to a private URL, killed if it does not earn a longer life.
Naming the folder makes the practice intentional. The lab keeps a steady cadence of prototypes specifically because they are where the structural learning happens. Production work consolidates. Prototypes expand.
How a prototype gets scoped.
One question, one week, one repo. The question has to be specific. 'Can I use streaming SSE to render a model response in this UX' is a prototype question. 'Should the lab use AI' is not.
The week-long bound is real. If the prototype has not produced an answer by the end of the week, the prototype is the wrong shape. Either the question was too big, the tooling was wrong, or the prototype is secretly a real project in disguise. All three are fine; all three need a different folder.
A prototype that runs long has stopped being a prototype.
What I have learned from the survivors.
The prototypes that survived and became patterns in the lab share a few things. They were honest about the thing they were testing. They were boring on every axis except the one they were testing. They produced a one-page note that captured the lesson, so future-me did not need to re-derive the answer.
Specifically, the work that survived built the dock physics, the route morph patterns, the small-model orchestration ideas, and the FAQ-first content structure used across this site. Each started as a one-week test. Each earned its way into the lab's default toolkit.
- Honest about what is being tested
- Boring on every other axis
- A one-page note at the end, every time
- Killed or absorbed, never left half-alive
What I have learned from the failures.
Far more than from the survivors. The failures cluster into patterns. Trying to test two things at once, so the result is ambiguous. Choosing a stack the prototype does not need, so the learning gets tangled up in tooling. Skipping the writeup at the end, so the next time the same question comes up, the answer has to be re-derived from scratch.
Naming these patterns has slowly tightened the prototype loop. The discipline now is one variable, smallest possible stack, writeup before you close the repo.
Where prototypes go from here.
The folder will get specific case studies as prototypes earn the writeups they deserve. The blog will host the longer notes; this page will host the index. Some prototypes graduate into Concepts, some into Projects, and some into a quiet line that says, 'tried, did not work, here is why'.