Verbs before varnish
The production rule that stopped me from polishing work I was about to throw away.
I’m building a 12-room game zone solo. For the first few rooms, I did what feels natural: finish each one completely before moving on. Layout, mechanics, lighting, sound, particle effects, the works. Room done, next room.
Then playtesting started telling me things. One room needed to be split in two. Another was dead weight and got cut. The pacing audit said two rooms should swap positions and one needed a completely different mechanic.
Every hour of polish on those rooms was gone. Not “needs rework” gone. Deleted gone.
This is the most common way solo builders lose time, and AI makes it worse, not better. When polish is cheap to produce, you produce more of it, earlier, on things that haven’t earned it yet.
The rule
Every piece of work has two kinds of tasks in it:
Verbs — the things that change what the thing does. Does the room play? Does the feature work? Can a user get through the flow? Do the core numbers feel right?
Varnish — the things that change how it looks and feels. Lighting. Animations. Copy polish. Edge-case hardening. The shimmer.
The rule is: lock the verbs across everything before you varnish anything. Build one layer across many rooms, not every layer on one room.
The test for any task takes one second: does this change how it works, or how it looks? Works means now. Looks means later, batched.
I didn’t know it at the time, but this has names. Developers call the idea “tracer bullets” — it’s in The Pragmatic Programmer, a book older than some of the people using AI to code. Game studios call the polished-early piece a “vertical slice.” I locked my version of the rule before I’d heard either term, which is exactly why I trust it: arriving at an established practice from a different direction, by paying for its absence, is better evidence than reading about it.
Why batching the varnish matters
When varnish time finally comes, you don’t polish item by item. You do one discipline across everything — all the lighting in one pass, all the sound in another. Two reasons:
- You stay in one toolset and one headspace, and you accelerate within the pass. Finishing things one at a time means context-switching across every discipline every time, which is the slowest possible arrangement.
- By then you know where polish is worth spending, because the whole thing has been tested. Twelve functional rooms teach you more about what’s fun than three perfect rooms and nine empty ones.
The one exception
Pick one small piece and finish it completely, early. In my case, three rooms out of twelve got full polish immediately.
That slice does three jobs. It’s the quality bar every other piece eventually gets raised to. It’s what strangers judge when you show your work. And it’s your morale anchor — one gorgeous finished thing to look at while everything else stays deliberately rough.
One slice. Not four. The exception exists to serve the rule, and it will try to grow.
Where this applies beyond games
Everywhere I build, it turns out. An app is verbs (auth works, data saves, the core loop functions) before varnish (empty states, animations, onboarding copy). A marketing site is verbs (the offer is clear, the form submits) before varnish (the scroll effects). A content system is verbs (the pieces get produced and published) before varnish (the template redesign).
The failure mode is identical in all of them: polishing something because polish feels like progress, then learning from contact with reality that the shape underneath was wrong.
Lock the verbs. Defer the varnish. Let the playtest — whatever the playtest is for your thing — tell you where the polish goes.