Demo data corrupts real data
A sales rep wants to show a prospect. They log into the production tenant and create a fake event. Real reports pick it up. Real reconciliation accounts for it. Real embarrassment follows.
Seed & Reset
Realistic demo data. Production data never touched.
A seed-pack framework for sales demos, QA environments, and customer onboarding — with a hard-coded safety boundary that makes running seeds against a real customer impossible. Realistic data, reversible teardown, full audit.
Live
Fake data should never touch real data.
Demo data, QA data, and onboarding data all have the same requirement: look real, behave real, and never, ever, contaminate a production tenant. Demos is built around that boundary first.
Fake data that looks fake
The test data everyone ships with is obviously synthetic — all the names are "Test User 1," the dates are 2023, the budgets are $1. Prospects disengage in seconds.
QA resets take a day
A QA engineer needs a clean test environment. The reset script is a 47-step Notion doc. Half the steps don't apply anymore. The environment never actually resets.
Onboarding means starting blank
New customers open the product to an empty tenant. They don't know what to click. They don't know what value looks like. The first login is the worst experience.
A seed framework worth writing packs for.
Every capability makes seed packs first-class code — versioned, reproducible, reversible, and traceable. QA, sales, and onboarding all pull from the same shelf.
Seed packs as contracts
Every seed pack declares its id, version, modules covered, and idempotent apply / plan functions. Packs are first-class code, not a pile of SQL fixtures.
Realistic, event-specific data
The event-agency-starter pack ships 12 vendors, 5 events, 15 deals, 3 budgets, 5 work orders, 8 reservations — realistic names, realistic costs, realistic dates. A demo that feels like a demo.
Per-row tagging for teardown
Every row created tags into platform.seed_rows with the pack id + application id. Teardown is deterministic — no orphaned rows, no manual cleanup.
Hard block on production tenants
Every apply/reset checks organizations.is_production. No application-code path can run seeds on a real customer. Ever.
Plan before apply
Every pack has a plan function that previews what would be created — counts per table, sample rows, expected totals. Dry-run is a first-class operation, not a guess.
Audit trail on every apply
Seed applications log to platform.seed_applications with the actor, timestamp, pack version, and counts. QA reproduces bugs by re-running the exact same seed. Sales demos are tagged and trackable.
Cross-module coverage
A single pack can seed Sales deals, Budget line items, Suppliers vendors, Dispatch work orders, and Spaces reservations — all in one transaction, with cross-module links preserved.
Typed org slug confirmation
Applying a pack requires typing the target org slug exactly. Resetting requires the same. Foot-gun protection for admins in a rush.
Safe by Default
Two hard locks between seed data and real data.
Seed packs cannot run on a production tenant — not by mistake, not by override, not by anyone. The safety boundary lives at the code level and at the data level.
Code-level block
lib/seeds/safety.ts::assertNotProduction(orgId) is called before every write. If organizations.is_production = true, the pack throws. No application-code path can bypass the check.
Org-level flag
Real customer tenants have is_production = true. Demo and QA tenants don't. The Demos module is disabled entirely on production orgs via a feature flag — double hard-block, belt and braces.
Get Started
Demo data that never lies to your customers.
The platform is live. Request a demo to see the Demos module in action.
Part of a 13-module platform that adapts to your operation. No commitment required.