Review the actual feature, not a screenshot of it

A preview environment is a complete, disposable copy of the application, created automatically for every feature branch and destroyed when the branch merges. No tickets, no "can someone refresh staging," no queueing behind another team's half-tested feature:

• Push a branch → the pipeline builds it and provisions an isolated environment: application, database, queues, seeded data.
• A unique URL (pr-318.preview.client.axiora.dev) is posted to the pull request within minutes.
• Every push to the branch updates the environment in place — reviewers always see the latest.
• On merge or close, the environment and all its resources are destroyed automatically. Nothing lingers, nothing bills.

Empty databases hide bugs: pagination that breaks at 1,000 rows, names that overflow layouts, the empty-state screen nobody designed. Production data in previews is the opposite mistake — a compliance incident waiting for a screenshot. We thread the needle with anonymized seeding:

• A seed dataset is generated from production shape — realistic volumes, distributions, and edge cases — with every identifying value replaced (names, emails, amounts perturbed, free-text scrubbed).
• The anonymization pipeline is one-way and audited; previews are classified as non-sensitive environments because nothing sensitive ever enters them.
• Edge-case records are deliberately included: the 400-character company name, the user with 10,000 orders, the account in a right-to-left locale.

Preview environments quietly fix the worst meeting in software: the sign-off review built on screenshots and trust. Instead:

• Product managers click through the actual feature the day it is ready — feedback arrives while changing course is cheap.
• Designers review real rendering, real data, real breakpoints — not a Figma-to-reality approximation.
• Clients and stakeholders get the URL too: sprint demos become "try it yourself" instead of "watch me drive."
• QA runs exploratory testing against an isolated environment where breaking things is free.

The cultural effect compounds: when seeing working software costs nothing, people look earlier, and disagreements happen at the sketch stage, not at the launch gate.

• Previews run on small instance sizes — review-grade, not production-grade. Typical cost: well under a dollar per day per environment.
• Idle previews sleep: no traffic for a few hours → scaled to zero, woken on the next request in seconds.
• TTL backstop: any preview older than 14 days is flagged and then reaped, even if the branch lingers — forgotten branches do not become forgotten bills.
• Per-project ceilings cap concurrent previews so a branch-happy week cannot surprise anyone.

Previews are for functional review, and we are explicit about what they do not prove:

• Not a performance environment: small instances and seeded data cannot validate load behavior — that is what load testing and game days are for (see Autoscaling).
• Inbound webhooks from third parties need routing setup per provider; where impractical, we replay captured webhook fixtures instead.
• Long-lived state (a 90-day subscription lifecycle) cannot be observed in a 3-day preview — those paths get time-warped test harnesses.
• Anything depending on production-only data volume (search relevance at 10M documents) is validated in staging against a full-size index.