The one decision I make before writing a single line of UI

Across six different products, the thing that kept them maintainable wasn't the framework or the styling. It was deciding, before any UI got built, what shape the data would take, and not letting each component invent its own version.

Orqestra is the clearest example: every section type — hero, FAQ, testimonials, CTA — has a fixed editable schema instead of a freeform block, and that is what lets one theme change propagate correctly across the site. Product Studio does the same thing from the other side: its audit engine is a fixed 38-check pass over real HTML, not an LLM improvising a finding, because reproducible results depend on a clear definition of what counts. This site works the same way too: every project is one object in an array with a fixed shape, which is why adding a new case study is a short edit instead of a hunt through components.

The temptation to skip this step is real, especially early, because a schema feels like overhead when the data is still fuzzy. But every time I've skipped it, the cost showed up later as a UI that could not be extended cleanly or as a mismatch between two screens that were supposed to show the same thing. Deciding the shape first is not a documentation task. It is the architecture decision, and everything else follows from it.