Backlot: Notes on Building a Reusable Demo Engine for SaaS

I have spent a lot of time lately thinking about a specific kind of friction that shows up across SaaS businesses: building product demos. A good demo of a conversational AI platform has to feel real, but standing one up is mostly plumbing you throw away afterwards. So I built a harness to fix that, and used it to put together a full customer journey on Genesys Cloud.

Here is the finished thing first. The demo is below, and a companion video on how it was built is under that. The code is on GitHub: the backend harness and the web frontend. Everything you will see is real, working configuration running against a backend I built and host. It is a sandbox for showing the platform, not a production system.

The Idea

The demo work should happen in the product UI, where the actual story lives, not in throwaway backend code you rebuild every time. So Backlot exposes a stable set of APIs and some synthetic customers, and everything that changes between demos is data rather than code. A new customer, a new industry, a new scenario is a new seed pack, not a new codebase. The same backend that plays a telco can play a bank or an insurer.

What the demo shows

The journey follows one customer, Anne, through one evening of bad WiFi. She lands on a help page, and instead of waiting for her to hunt for support, the site reaches out. An agent verifies her, runs a diagnostic, and finds a couple of real problems on her home network. It explains what is wrong in plain language, asks permission before it touches anything, fixes the issues, and confirms the network is healthy again.

Then, because the underlying problem is solved, it notices a coverage gap and offers a relevant upgrade. She can take it there and then, or hand off to a human. If she buys, the order actually gets placed. The demo video walks through all of it.

The interchangeable part

This is the bit I am most pleased with. A tenant is the customer you are demoing to, and everything about them lives in a seed pack: their name, their industry, their data, and the scenarios you can stage. Adding a new industry does not mean touching code. You drop in a new pack and the same engine serves it. Staging a fault is one button in an admin console; resetting between takes is another.

The frontend follows the same idea. The customer-facing site is built to be reskinned, so the same journey can wear a different brand, or a different industry's clothes, without a rebuild.

Observability, again

Regular readers will know I have a thing about not flying blind. The demo closes on analytics: the business outcomes the journey produced, the milestones it hit, and the whole customer journey as a single view. It is the same instinct behind my home lab. A system you cannot measure is a system you do not really understand, and here it turns the conversation from a black box into something you can attribute and reason about.