Why I build a component page for every project

For every larger project, alongside the app itself, I build one extra page that the client or end user will never see — a component/typography page. It's a single route, usually /styleguide or /dev/components, excluded from indexing, where the entire type scale, every button, card and badge variant, and the color palette are rendered in one place.

The reason is simple: once a project grows past a few pages, small inconsistencies start creeping into the code — a slightly different gray used for "muted" text here, a slightly different border-radius on a card there, a different gap between an icon and its label somewhere else. Each one is unnoticeable on its own, but together they make the app feel visually disjointed.

The component page acts as a litmus test. It renders the exact same variables and Tailwind classes the production code uses — not separately hand-copied example values, but the same tokens. When I add a new button variant or change a border-radius value, I immediately see everything it could affect, side by side, before it accidentally breaks something else in the app.

We went through exactly this on this site over the last few days — the testimonial card, the avatar, the spacing around the text — it took several iterations before we landed on the final look. If I'd had one page from the start showing that card next to every other card on the site, I'd have saved a lot of those rounds.

In larger systems like Cleenly or Syntha, running hundreds of components across dozens of screens, this matters twice as much. Without one place where you can see everything hierarchically, side by side — from base elements through composed components to full sections — it's practically impossible to manually verify that every one of them still meets current UI and UX standards. The component page doubles as a checklist: run through it before every larger release and immediately see what's falling behind.