The awkward bit is when a convincing interface still has a route into the production application. Disabling the checkout button doesn't tell you whether another action can reach the same service. What matters is what the deployed build can actually do.

Livid's public competition showcase gives somebody a way to browse sample prizes, inspect entry options and see an illustrative balance change. That is enough to explain those parts of the experience. Fictional records do the job, provided the prizes, balances and simulated outcomes are labelled clearly.

Keep the public showcase separate from private integration testing and production. A fixture-only build explains the experience. A payment provider's test environment helps you check an integration. Production performs real operations. They need their own checks; a successful showcase walkthrough doesn't prove that payments or fulfilment work.

For the public build, trace the actions someone can take, including navigation, form submissions, background requests and error paths. Check the configuration and inspect the deployed network traffic. Look for production endpoints, embedded credentials and service connections the demo doesn't need. Giving it a separate deployment makes this easier to inspect, but it still needs inspecting.

State deserves the same attention. In-memory state can keep a journey going through internal navigation and disappear when the page reloads. Browser storage has different behaviour. For example, sessionStorage survives reloads within its page session. Choose the behaviour deliberately, and make sure any claim about refreshing matches what the implementation does.

Unsupported actions need an honest ending. If checkout isn't available, say so where the visitor reaches it. An apparent order confirmation can make somebody think they have bought something. Simulated wins need visible labelling for the same reason. A visitor shouldn't have to guess which parts are real.

The October source review of Livid's showcase documented an independent demo with fictional prizes and an in-memory visitor. The reviewed package excluded checkout, authentication, payment and email services. Its state was documented as surviving internal navigation and resetting on refresh. That describes the implementation reviewed at that point. It doesn't certify future deployments or validate the operational product's transaction flows.

That distinction also matters when somebody evaluates the wider Livid Competitions platform. The public showcase demonstrates a customer journey; reviewing the tools and integrations behind the operational product is separate work.

Before releasing a demo, walk through the deployed version again. Try direct links, reloads, a new tab and a narrow mobile viewport. Follow the awkward paths too: repeated clicks, unavailable actions and errors. The demonstration should still be understandable when something isn't supported.

If somebody can follow the journey and tell which parts are simulated, the demo has done its job. Whether the operational product can take a payment or deliver a prize needs its own evidence.

Engineering notes from Livid.