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

Across six very different products — a multi-agent research assistant, a UX audit studio, a website builder, an election analytics dashboard, a workflow engine's docs site, a browser extension — the thing that made each one maintainable wasn't the framework or the styling. It was deciding, before any UI got built, exactly what shape the data would take, and refusing to let a component invent its own version of that shape.

Orqestra is the clearest example: every section type — hero, FAQ, testimonials, CTA — has a fixed, editable schema rather than a freeform block, and that constraint is the only reason a single theme change can propagate correctly across every section at once. Product Studio does the same thing from the opposite direction: its audit engine is a fixed 38-check pass over real HTML, not an LLM improvising an opinion, because a deterministic schema for 'what counts as a finding' is what makes results reproducible run to run. Even this site works the same way — every project is one object in an array with a fixed shape, which is the entire reason adding a new case study is a five-minute edit instead of an afternoon spent hunting through components.

The instinct to skip this step is strong, especially early, because a schema feels like overhead when you don't have real data yet. But every time I've skipped it, the cost showed up later — either as a UI that couldn't be extended without a rewrite, or an inconsistency between two screens that were supposedly showing the same thing. Deciding the shape first isn't a documentation exercise. It's the actual architecture decision, and everything downstream — including which framework or rendering strategy makes sense — follows from it, not the other way around.