How I Design Posters Before Writing Code

SAMPLE POST — replace with the real drafted post (Week 0 audit). This is the second §4A "personality post" in the launch set.

Before I write code for a project, I design its poster. Not a wireframe, not a logo — the actual promotional poster I'd put on a wall the day it launches. It sounds backwards. It's the most useful habit in my process.

The poster is a forcing function

A poster has room for one headline, one image, one reason to care. If I can't fill those three slots, the project isn't ready to build — I don't have a product problem, I have a clarity problem, and code won't fix it.

It sets the quality bar

Once the poster exists, the product has a promise to keep. Shipping a UI that looks worse than its own poster feels like a lie. The poster drags the build quality upward the whole way.

It's cheap

A poster is an evening. A build is weeks. Discovering that an idea has no headline costs one evening this way — instead of costing the whole build.

The workflow

1. Write the headline (the outcome, not the features).
2. Design the poster around it.
3. Put it somewhere I'll see it daily while building.
4. At launch, use the actual poster — it was the plan all along.

The poster-first habit is why the case studies on this site all start with "Spark" and "Shape" before "Build". The order isn't a template — it's how the work actually happens.