Synthetic data

Empty preview environments lie

Preview deployments were a big step forward: every branch gets a URL. But open one and you usually find an empty app, a single test account, or a database someone seeded by hand two years ago. A preview like that can't show you what a real customer will see.

What empty data hides

  • The power user. Tables with 4,000 rows, pagination, slow queries, crowded dashboards.
  • The first login. Empty states, onboarding steps, the moment a new user decides whether to stay.
  • The edge state. A suspended workspace, an expired trial, a user removed from a team. These are the screens most likely to crash and the least likely to be tested.

Why copying production is the wrong fix

The quick answer is to clone production into each preview. Database branching makes that fast. But it puts real customer data, including personal data, into every preview environment and every pair of eyes that opens one. Under GDPR that is a risk most teams shouldn't take, and anonymizing a copy is easy to get subtly wrong.

Personas: data with a point of view

A persona is a named user state: who they are, which organization they belong to, its status, and how much history they have. For example:

seed: 42
personas:
  - id: admin
    role: ADMIN
    org: { name: "Acme BV", status: active }
    history: large        # about 6 months of activity
  - id: new-user
    role: MEMBER
    org: { ref: acme }
    history: none
  - id: suspended-tenant
    role: OWNER
    org: { name: "Defunct BV", status: suspended }
    history: medium

Adaptl turns that file into real rows, consistent across every table, and gives each persona a login the app accepts. Same seed in, same data out, so a bug found today can be reproduced tomorrow.

Through the app's own models

Most seeders write straight to the database. That skips the rules that live in your application code: validation, signals, computed fields, password hashing. The data looks fine until the app reads it and breaks.

Adaptl writes through the app's own models where it can (SQLAlchemy and Django today), so those rules run. For apps without a supported ORM, a raw-SQL path declares app-specific steps such as password hashing in a small mapping file.

Then the personas use the app

Data alone still looks frozen. Adaptl runs a short scripted journey per persona: the admin creates a product and refunds an order, a customer books a slot. The preview then has recent activity, and you get a trace and a plain-English summary of what each persona did.

Zero PII, by design

Adaptl reads schemas and code, never production rows. Generated emails use reserved domains such as example.com, so nothing can reach a real inbox.

Try your next change as your customers will

Adaptl previews every change your coding agent makes with realistic, made-up customers, so you can pin what's wrong before it merges.

Start free

Keep reading