Demo engineering
A demo is an argument.
Most demo data cannot make one.
The demo automation industry spent a decade solving the surface of this problem, and solved it well. You can now record a product, overlay a guided tour, swap the logo, and ship a personalised walkthrough without writing code. None of that helps you if what you sell is a warehouse, a pipeline, or an agent, because those products have no surface. The data is the product. And demo data is the part nobody fixed.
is what one team allocates purely to keeping demo environments standing. An unnamed sales leader: “I’ve allocated two, well-paid, FTEs that I’ve had to carve off for it and I really wish I could use them elsewhere.”
Sam Senior, TestBox, March 2026, from 100+ leader interviews (speaker anonymous)is how long demo data stays current. “After just one or two days, we’re already falling behind.” A shelf life measured in days, not months.
Sam Senior, TestBox, March 2026for the configuration changes behind a single tailored demo, and that is the fastest person on the team, not the average one.
Sam Senior, TestBox, March 2026is what custom data processing agreement negotiations add to a sales cycle, which is the wall you hit the moment a POC needs real customer data.
Secure PrivacyEvery figure above was checked against the page it links to, not against a summary of it. Where a source describes one team rather than an industry, it says so, and where the person quoted is anonymous we say that too. Three of the four come from one vendor\u2019s research, which is worth knowing when you read them. We publish no number we have not read in its original context, including our own.
The part that is never said out loud
A demo is not a dataset. It is a claim about the world, made in front of someone deciding whether to spend money. The claim is usually something like: your on-time delivery is quietly degrading and you cannot see it, and this product would have caught it in July.
For that demo to land, the degradation has to be in the data. Not approximately, not on average, but sitting in Q3 where you promised the prospect it would be, visible in the dimension you promised, and consistent with every other table they might click into. The data has to contain the argument.
This is why generating plausible rows is not the same as generating a demo, and it is the distinction almost every tool in this category misses.
Twelve plausible months. Every value defensible on its own, and no month is wrong. There is also no moment where your product is needed, so there is no demo here to give.
The same schema and the same row count, with three facts declared before any row existed. The SLA breach in Q3 is the demo. It is the reason the alerting feature has something to catch.
Five ways teams solve this, and what each one costs
Nobody in this industry is lazy. Sales engineers are among the most resourceful people in any software company, which is exactly why the persistence of this problem is interesting. Every available path forces a real trade.
Legally radioactive. Custom data processing agreement negotiations add 4 to 12 weeks to a sales cycle before a single row moves, and the security review sits on top of that.
Needs the real data first, so it inherits the entire delay it was supposed to remove. You still cannot start on day one.
An order-management benchmark from the 1990s that engines compete on. Parts, suppliers, and nations. It is not your prospect's industry and it tells no story about their business.
Fills columns one at a time with no idea what the neighbouring column says. Survives until the first JOIN or the first GROUP BY, which is roughly slide four.
Works once. Then the prospect asks what Q3 looks like in the Nordics, and you are rewriting inserts at eleven at night before a Thursday call.
Surface products and substance products
It is worth separating two kinds of software, because the demo problem is completely different for each and the industry mostly talks about one of them.
A CRM, a project tracker, a marketing suite. What the buyer evaluates is the screen. Demo data only has to look right at the resolution a human eye reads it, and the mature demo platforms handle this genuinely well by intercepting the render and substituting values.
This problem is solved. Buy one of the good tools.
A warehouse, a pipeline, a transformation layer, an agent that acts on records. What the buyer evaluates is what happens to the data. They will run their own query. They will click into the detail behind the number. There is no render to intercept, because the computation is the product.
This problem is not solved, and overlays cannot reach it.
The gap matters more every quarter, because the fastest-growing category of software right now is agents, and an agent is the most substance-shaped product there is. It reads records, decides, and writes records back. You cannot demo that with a screenshot. You need real rows for it to act on, and you need to be able to prove afterwards that what it did was correct.
What good actually looks like
Three properties, and they are unusual together. Most tools have one.
You state that the year totals 87% and that Q3 breaches the SLA, and the rows are solved to land on it. Not approximately. The demo you rehearsed is the demo you give.
Every foreign key resolves, every roll-up reconciles with its parts, and no timestamp contradicts another. The buyer who opens the detail behind a number finds a real one.
Declared against actual, orphan counts, coherence findings. Not a promise that it is fine. A check you can run yourself before you put it in front of a seven-figure prospect.
Misata Backlot
A backlot is the standing set at a film studio: a convincing world built once, then reused across many productions. Backlot is an agent that builds one for a deal. You describe the prospect, it proposes a warehouse for their vertical, you declare what has to be true about the numbers, and it generates, verifies, and lands the data in Snowflake, BigQuery, Postgres, or files.
Series B logistics company, 40 warehouses, EU and US, the champion cares about carrier cost overruns.
On-time at 87%, breaching in Q3, Nordics worst. The engine solves the rows to land on it exactly.
Make the Nordics worse. Add a carrier late 30% of the time. The other declarations stay put.
Declared against actual for every figure, zero orphans, coherence checked. The reason you can risk it.
Backlot is not shipped yet. The engine underneath it is: Misata is MIT licensed and on PyPI today, so you can read exactly how a declared aggregate is solved rather than taking our word for it. The warehouse generator runs the same declaration machinery in your browser with no signup.
Questions
What is demo engineering?
Demo engineering is the discipline of building and maintaining the environments, data, and assets a sales team demonstrates a product with, as a dedicated function rather than something each sales engineer improvises per deal. The role exists because demo quality stopped scaling with headcount: adding sales engineers just adds people building one-off environments. A demo engineer builds the reusable substrate instead.
Why is demo data the hard part of demo engineering?
Because a demo is an argument, not a data dump. The data has to contain the specific thing the product is supposed to catch, fix, or reveal. It also has to be internally consistent across every table a prospect might click into, and it has to be time-relative, since a dashboard showing activity from 2022 dates the environment instantly. Most generators produce plausible values one column at a time, which satisfies none of those three requirements.
Why can't demo automation tools solve this for data products?
Interactive demo platforms work by intercepting what renders on screen and substituting demo values, which is genuinely effective for an application with a user interface. When the product being sold is a data warehouse, a pipeline, or an AI agent, there is no surface to paint. The data is the product. You cannot overlay a pixel onto a GROUP BY, and a buyer who runs their own query sees straight through it.
Why not just use the customer's real data in a POC?
Most teams try, and it is a large part of why POCs drag. Before production data moves anywhere, there is usually a data processing agreement and a security review, and custom DPA negotiations extend sales cycles by 4 to 12 weeks on average. That leaves a long window at the start of every enterprise data deal where the sales engineer is blocked, and the only unblocked path is data the vendor generates themselves.
Isn't the sample data bundled with Snowflake or Databricks enough?
Both bundle TPC-H, an order-management benchmark that database engines have competed on for decades. It is deliberately generic rather than industry-specific: customers, orders, line items, parts, suppliers, nations, regions. It is excellent for benchmarking a query engine and useless for showing a healthcare, logistics, or insurance buyer their own business. Synthetic data that mirrors the customer's schema and distribution is far more convincing than generic sample data.
What is Misata Backlot?
Backlot is the commercial product proposed at the end of this article: an agent that takes a plain-English brief about a deal, designs a warehouse for that vertical, lets you declare what has to be true about the numbers, generates the data, verifies every declaration held, and lands it in Snowflake, BigQuery, Postgres, or files. The engine underneath is Misata, which is open source and MIT licensed, so you can read exactly how a declared aggregate is solved rather than trusting a black box.
Written by the team behind Misata, an open-source engine for generating relational data that satisfies declared outcomes exactly. If you run demos on a product where the data is the product, we would genuinely like to hear how you solve this today, including if the answer is a script you are not proud of. Tell us.