Engineering · Blog
How we embed and capture demos from the running app.
Marketing sites love screenshots. Screenshots age. They also lie carefully: lit, cropped, and carefully not the build you will get after procurement signs and the implementation partner discovers the demo data was theatre reserved for the sales environment.
Every CEDX product page embeds the real app. Feature bands use captures from that same build. If a screen is wrong, we fix the product, not the PNG. That is operationally harder and commercially cleaner. It forces demo data quality, embed performance, and trial modes to be first-class product work instead of marketing debt.
Prospects ask a simple question: does it look like this. There is one answer when the page is the product. Partners send the same URL they will implement against. No bait-and-switch deck. No shadow environment that only sales can log into on Tuesdays with a scripted dataset that never survives first data import.
This policy also kills a class of sales enablement debt. Battlecards can link to the live motion. Academy can open the app after a checklist. Webinars can refuse to run if the app will not open. Partner labs certify on the same build customers buy. Training screenshots stop being a versioning crisis.
If you are comparing vendors, demand the live path. A beautiful static site with a separate demo environment is a risk signal, not a polish signal. The seam between marketing and product is often the same seam that will hurt your operators later when training uses screenshots from two versions ago and support cannot reproduce the ticket.
Engineering pays a tax for this honesty: embed modes, performance budgets, and demo tenants that do not collapse under a webinar spike. That tax is cheaper than a brand that cannot survive a shared screen in a procurement review when a technical buyer asks to click around without a guided path.
Customer scenarios on this site follow the same rule. Illustrative narratives sit next to product embeds and catalog links. You are not asked to believe a PDF alone. You are asked to open the software and walk the motion with the same identity plane the story describes.
When something on a page drifts from the build, the bug is the product or the capture pipeline. It is not a design opportunity to invent a prettier falsehood. That discipline is why the estate story stays coherent as the catalog grows past a hundred live product surfaces without a second marketing universe.
Screenshot marketing creates a second product: the one that exists in Figma exports and the one that exists in production. Teams then staff two truths — enablement on fiction, delivery on reality — and customers notice mid-pilot.
Live embeds force demo data quality, performance, and permission models to be real. Those are the same properties customers need after signature. Marketing pressure becomes product investment instead of debt.
Partners should treat the public product page as the source of demo truth. If your internal demo tenant diverges without a reason, fix the tenant. Do not fix the story by editing screenshots.
Webinars that cannot open the app should be postponed. A slide-only session teaches attendees that the product is optional. That lesson is expensive to unteach.
Procurement screenshares are the moment of truth. If a technical buyer can click without a scripted tunnel, trust compounds. If every click requires a pilot guide to avoid broken paths, trust evaporates regardless of brand polish.
Engineering
If this essay points at a product, open the live app - not a parallel mockup universe.
Takeaways
Open three live apps on one user and follow one customer record.
Write three metrics and a retire list before config sprints.
Use path pages and tiers if you sell or implement the estate.
How we embed and capture demos from the running app.
