Why I Plan With HTML Before I Build

I like planning with HTML files because they force the plan to become visible.

A text document can hide weak structure. A long note can feel complete because it has a lot of words. HTML is less forgiving. If the idea has no hierarchy, the page feels flat. If the sequence is wrong, the navigation exposes it. If the plan has no concrete decisions, the sections feel empty.

That is useful.

An HTML plan is not a fancy deliverable. It is a small interface for thinking. It lets me see the project as a thing someone will actually use: sections, anchors, tables, cards, decisions, risks, next steps. It becomes easier to ask whether the plan is scannable, whether the important parts are first, and whether the work has a shape.

It also creates a better bridge between strategy and execution. A good HTML plan can hold editorial direction, user flows, system behavior, implementation slices, QA notes, and open questions in one place. It is readable by a client, useful to a developer, and concrete enough to survive the handoff from idea to build.

Planning this way also changes how I use AI. Instead of asking for random output, I ask AI to help fill a structured artifact. The structure creates pressure. It asks for decisions. It reveals gaps. It makes the model useful without letting it take over the thinking.

The plan is not there to slow the work down. It is there to make the work less vague before speed becomes expensive.

I still sketch. I still write messy notes. But when a project matters, I like turning the thinking into a browser-readable artifact. Not because HTML is magical. Because the browser is where the work will eventually live, and the plan should already understand that world.

— Victor