Backlot

Studio makes a dataset whose tables show your numbers. Backlot goes one step further: it makes the numbers come out of someone's own pipeline. You bring the pipeline (a dbt project, or a Postgres schema), say what its dashboards should show, and Backlot builds raw source data, runs the pipeline on it unchanged, measures what the pipeline produced, and corrects the source until the output tells your story.

Use it when the demo is the pipeline: a BI tool, a dashboard product, a semantic layer, an AI analyst or a workflow tool, shown on data that flows through real models rather than straight into a chart.

The steps#

Step	What happens
1. Bring the pipeline	Upload a dbt project (zipped) and Backlot reads its sources, models and tests. Or connect a Postgres database and it reads the schema, or paste DDL. A template brings all of it.
2. Tell the story	One or more scenes: a number, a window and a shape. "Collected revenue from 42k to 96k over the year, a 25% drop in month seven." Backlot drafts the scenes from what you wrote about the prospect and the product; you edit them.
3. Build	The verified engine makes the source tables, each scene held as an exact monthly total on its source table.
4. Seed	The data is loaded into a sandbox: Misata's own (nothing to connect) or a schema Backlot creates in your Postgres, after showing you the plan.
5. Run and prove	In the Misata sandbox, Backlot runs the dbt project itself. On your own Postgres, your pipeline builds its models as it always does. Each scene is then measured on what the pipeline produced, with its own SQL on the model the dashboard reads.
6. Solve	Where the pipeline's logic moves a number (filters, joins, deduplication), Backlot corrects the source month by month and runs it again, until every scene holds within 2%. Every step is kept, so you can show the path.
7. Share	A demo room link, a reset webhook, an agent endpoint, and an event replay for workflow tools.

Start from a template#

Four ready pipelines run in the Misata sandbox with one click. Each has a dbt project, its source tables and a story:

Template	For	The story
Subscription revenue	BI and analytics vendors	Collected revenue climbs all year, drops a quarter when the largest customer pauses, then recovers; new accounts jump with a spring campaign
Storefront sales	E-commerce analytics, CDP and marketing tools	Orders, revenue and channel mix, with a holiday peak and a launch that lands
Payments and disputes	Fintech, fraud and risk tools	Volume grows while a card-testing attack spikes disputes, then new rules bring them down
Support desk	AI support agents and helpdesk tools	Tickets across email, chat and phone, with a launch-week surge, ready for an AI agent to query

Put the prospect's name in For and the demo carries it. Backlot uses only what you write about the prospect; it never invents facts about them.

What you can hand a prospect#

• The demo room: a link anyone can open with no account. It shows the story, what the pipeline measured for each scene, and a read-only SQL console over the sandbox (raw tables, the pipeline's models and seeds). It never shows how to reach the database.
• Reset: one button in the room (and a webhook for n8n, Zapier, Make or a CI job) reloads the same build, runs the pipeline and proves every scene again, live. Use it before a demo, or after a prospect has played with the data.
• An agent endpoint: the room is also an MCP server, so an AI agent can list the tables, describe one, query the sandbox and read the story. Point an AI analyst at it and ask it the story's questions.
• Event replay: send the story's rows to a workflow as events, in time order and in the story's monthly shape (the spike month sends more). Each event leaves out one fact the workflow must look up (the customer's tier, the merchant's category), and Backlot knows the right answer, so the workflow's replies are scored, not just counted.
• Download: the seeded data, to load anywhere else.

Good scenes#

• One number per scene, on the model the dashboard reads. "Revenue by month from fct_monthly_revenue" proves what the viewer sees. Without SQL, the scene is measured as the plain monthly total of its source column.
• A shape a person remembers. Growth with one dip and a recovery, a spike and its fix, a launch that lands. Two or three scenes carry a demo; more make it harder to tell.
• Numbers the pipeline can reach. If a model filters out cancelled orders, the source needs more orders than the output shows. Solve handles this, within the limits of what the source can carry.

Limits#

• Pipelines are dbt projects or Postgres schemas. Other warehouses are read through their DDL.
• The sandbox runs the dbt project in DuckDB. A project that relies on warehouse-specific functions may need a small change to run there.
• On your own Postgres, Backlot seeds and measures; it does not run your pipeline. Run it after each seed (the reset webhook lets a CI job do both), or measure scenes on the source tables.
• Solve stops when every scene holds within 2% or its budget is spent. A scene the pipeline's logic cannot reach (a number its filters always cut) is reported with the gap, never hidden.
• A connected database is used for the seed you approve, in a schema Backlot creates. Give it a user that can write only there.