On building scratchpads.

Most of what you ship started as a sketch on a napkin, in a Figma file you never opened again, or in a tiny app like this one. The scratchpad is the place where ideas are allowed to be wrong. It is cheap, throwaway, and quiet — and that is precisely what makes it useful.

When you build inside a real product, every change is filtered through six other concerns: routing, auth, analytics, the design system, the eight people who will review the PR. Each of those is worthwhile in isolation, but together they raise the activation energy of trying anything new to a level where you stop trying.

The iteration loop

Good interfaces come from tightening the loop between an idea and the next thing you learn from it. A scratchpad collapses that loop to seconds. You think of a layout, you type it, you see whether it holds up, and you decide what to keep. Repeat fifty times.

The repetitions are the point. The fiftieth attempt at a sidebar does not look like the first because by then your hand knows things your head does not yet. Taste is built out of those small motor memories — the spacing that felt right, the weight that did not, the affordance you reached for without thinking.

Scaffolds vs. polish

There is a temptation, when you have a fast environment, to polish every sketch into a finished thing. Resist it. The scratchpad is for scaffolds — the cheap framing of an idea that lets you decide whether it is worth building properly somewhere else.

Polish at this stage is a tax on exploration. Every minute spent picking the perfect shade of muted-foreground is a minute you are not generating the next idea. Sketch with the side of the pencil, not the tip.

The fastest way to taste is volume. Build a hundred bad layouts and the next ten will be quietly excellent — not because you tried harder, but because your hand learned what the brief did not say.

A few habits make scratchpad work compounding rather than disposable. Keep them small. Name them well enough that you can find them next month. Resist building infrastructure inside the scratchpad — the moment it starts feeling like a real app, fork the idea out to where real apps live.

• One idea per file. If two ideas want to merge, fork instead.
• No data layer. Hard-code everything. Real data is later.
• Steal shamelessly from your own past sketches.
• Throw away more than you keep, and do not feel bad about it.

Closing thoughts

The work that ends up in production is the visible tip of a much larger pile of attempts. The pile is not waste — it is the substrate from which the visible work grew. Treat the scratchpad with the seriousness of a sketchbook, not the seriousness of a shippable product, and the rest follows.

Now close the rails, dim the chrome, and write the next bad layout.