real-prototype

Build each variant as its own component on the existing route, keep the page's data fetching above the switch, and select the variant via a `?variant=` URL search param. Add a floating switcher bar so you can flip between variants live in the browser.

Real-prototype mounts variants on the live route so they are judged against real data, layout, and density. A standalone .html prototype never touches the app and is safer, but every option looks fine in isolation, which hides real design weaknesses.

Default to three variants, use two for a quick A/B test, and go up to four or five only when the design space is wide open. Cap at five, and make sure variants differ structurally in layout or hierarchy, not just color or copy.

No. The switcher and variant branching must be gated out of production builds using checks like `process.env.NODE_ENV !== 'production'`, so a stray merge can never expose prototype UI to real users.

No. Variants must stay read-only and point any write action at a stub. The goal is deciding what the page should look like, not testing whether the backend works.

Record which variant won and why, delete the losing variants and the switcher, then rewrite the winner to production standards as you fold it into the real page. Prototype code is built read-only with minimal error handling, so it should not ship as-is.