Two engineers, full time, just for the demo data

There is a line in TestBox's analysis of their last hundred-plus conversations with sales and GTM leaders that I have not been able to stop thinking about. A leader describing what it costs to keep their demos honest:

"I've allocated two, well-paid, FTEs that I've had to carve off for it."

Two full-time engineers. Not building the product. Keeping the demo environment from telling lies.

The same analysis found demo data has a shelf life "measured in days, not months," with one team putting it plainly: "after just one or two days, we're already falling behind." And for the configuration work behind a single tailored demo, one leader said the fastest person on their team still needs over eight hours.

I went looking into this properly over the last week, because it sits directly next to what Misata does and I wanted to know whether the problem was as bad as it sounded or whether I was pattern-matching. It is worse than it sounded, and the interesting part is not the waste. It is why it has survived a decade of tooling built explicitly to fix it.

What the demo industry actually solved

The demo automation category is not short of money or talent. Saleo, Navattic, Storylane, Reprise, Demostack, Supademo, Consensus, Arcade, and a dozen more have built genuinely good products, and if you sell a CRM or a project tracker you should buy one of them.

They work by intercepting what renders on screen and substituting demo values. Your dashboard says $4.2M because the platform painted $4.2M over whatever was underneath. For an application with a user interface, this is exactly right, and it is why those companies have real customers with real logos.

Now consider what happens when the thing you sell is a data warehouse. Or a transformation layer. Or a pipeline. Or an agent that reads records, decides something, and writes records back.

There is nothing to paint. The data is the product. A buyer evaluating a warehouse is going to run their own query, and a buyer evaluating an agent is going to watch it act on rows and then check whether what it did was correct. You cannot overlay a pixel onto a GROUP BY.

The industry solved the surface of the demo problem. Nobody touched the substance.

The other four options, and what each costs

If you sell a substance-shaped product, here is your actual menu today.

Use the customer's real data. Most teams try this first, and it is a large part of why POCs drag. Before production data moves anywhere, there is a data processing agreement and a security review, and custom DPA negotiations extend sales cycles by four to twelve weeks on average. There is a long window at the start of every enterprise data deal where you simply cannot start.

Mask a copy of production. This is what the privacy-first tools do, and they do it well. It also requires having the real data first, so it inherits the entire delay it was supposed to remove.

Use the sample data bundled with the platform. Snowflake and Databricks both ship TPC-H. It is an order-management benchmark that database engines have competed on for decades: customers, orders, line items, parts, suppliers, nations, regions. It is excellent for benchmarking a query engine. If you are demoing to an insurer or a hospital network or a freight company, it is a 1990s parts catalogue that says nothing about their business.

Generate it with Faker, Mockaroo, or a script. These fill columns one at a time, with no idea what the neighbouring column says. It survives until the first JOIN or the first aggregate, which in most demos is roughly slide four.

Build it by hand. Which brings us back to the two engineers.

The thing nobody says out loud

Here is what I think the actual problem is, and it took a week of reading to see it clearly.

A demo is not a dataset. It is an argument.

When a sales engineer stands up a demo, they are making a specific claim to someone deciding whether to spend money. 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 to land, the degradation has to actually be in the data. Sitting in Q3 where you said it would be. Visible in the region you said it would be. Consistent with every other table the prospect clicks into. The rows have to contain the argument.

This reframes what "realistic data" means, and it explains why every tool above fails. Faker has no concept of an aggregate. Masking gives you whatever story production happened to have, which is usually no story. TPC-H is frozen. Hand-written SQL can do it exactly once, and then the prospect asks what the Nordics look like and you are rewriting inserts at eleven at night.

Generating plausible rows is not the same as generating a demo. Almost nothing in this category understands the difference.

What we have started building

Misata has spent two years on one idea: you declare what has to be true, and the engine solves the rows to satisfy it exactly, then proves it did. Revenue lands on the figure. The rate is the rate. Every foreign key resolves and every roll-up reconciles, and there is a conformance suite and a paper behind the claim rather than a marketing page.

That is, it turns out, precisely the machinery you need to make an argument out of rows.

So we are building Misata Backlot.

A backlot is the standing set at a film studio: a convincing world built once, then reused across many productions. Backlot builds one for a deal. You describe the prospect in prose. It proposes a warehouse for their vertical. You declare what has to be true about the numbers, including the specific thing your demo turns on. It generates the data, verifies every declaration actually held, and lands it in Snowflake, BigQuery, Postgres, or files. Then you revise it by asking: make the Nordics worse, add a carrier that runs late 30% of the time. The other declarations stay exactly where you put them.

Every dataset ships with a certificate: declared against actual for every figure, orphan counts, coherence findings. That part matters more than it sounds. Nobody puts generated data in front of a seven-figure prospect on trust alone, and the certificate is the difference between hoping and knowing.

Being straight about where this is

Backlot is not built. It is specified, the engine underneath it exists and is open source, and the first end-to-end vertical is being built now. I would rather say that plainly than run a countdown timer over a landing page for something that does not exist yet.

Two things are genuinely undecided, and if you demo data products I would like your opinion on both. Which vertical is worth doing first. And whether the sharper pain is on the vendor side, where a sales engineer is prepping a demo for Thursday, or on the consultancy side, where a firm has to show a working solution to win the work but cannot get the client's data until they have won it.

The full argument, with every figure sourced and a chart showing the difference between plausible data and data that makes a point, is at misata.studio/demo-engineering. The waitlist is on that page. One email when there is something real to show, no sequence, and you will hear from a person.

Every figure in this post was checked against the page it came from rather than a summary of it, which is a lower bar than it should be and one this industry's content routinely fails.

If you have spent an evening writing INSERT statements so a chart would bend the right way before a call, this was built after reading about people like you.