Database seeding for demos that catches real workflow bugs

Why clean fake data causes trouble

Demo databases often start with records that look tidy on a screen. Every customer has a full name. Every company has one owner. Every order has a valid status. Every date lines up.

That kind of data is easy to show, but it does not behave like real usage.

Real products get messy fast. People leave fields blank. Teams create duplicate accounts. Old records survive process changes. Someone starts setup, quits halfway, and returns a week later. If your seed data removes all that mess, the product can look solid right up until a buyer, tester, or new hire clicks into a path nobody rehearsed.

Perfect data creates false confidence because it hides the places where software usually breaks. Filters look accurate when every record follows the same rules. Permissions look fine when each account has one clean role. Notifications look reliable when every email is valid and every status changes in the expected order. Then real users show up, and the cracks appear.

The first workflows to break are usually the ones with handoffs, exceptions, and old baggage. Trouble tends to show up in signups and invites with duplicate or unfinished accounts, approval flows where records skip a step, billing changes with failed payments or expired trials, and reporting screens where names, dates, or tags do not match.

A demo with spotless data can still impress someone for five minutes. It just does not tell you much. If the goal is a polished screenshot, clean sample records are enough. If the goal is to catch problems early, they are a weak test.

Good seed data adds a little friction on purpose. Include missing fields, old imports, odd status combinations, and records that look almost the same but are not. That is much closer to what support, sales, QA, and new employees will face on day one.

When the data feels slightly annoying, the product gets a more honest test. That is where the useful bugs usually appear.

What realistic seed data looks like

Realistic seed data looks like the data your team already deals with during a busy week. It has gaps, strange timing, repeated entries, and records that should have been cleaned up months ago but still exist. If your demo data only creates neat rows with perfect names, complete profiles, and happy path orders, it hides the problems people hit every day.

Start with records that feel messy, not unusable. Some users should miss phone numbers or company names. A few accounts should share the same billing contact. Some projects should have no owner because someone left and nobody reassigned them. Old records matter too, especially if your product keeps history, renewals, or audit logs.

State mix matters just as much. Real systems rarely have everything in one state at once. Your seed set should include records that are active, paused, failed, canceled, expired, and unfinished. That gives sales, QA, and new hires a more honest picture of the product.

A small sample set might include a customer who paid on time for six months, a trial user who never finished setup, an account with a failed payment and a paused subscription, two contacts with the same email stored in different formats, and an old canceled workspace that still has invoices and support notes.

Support tickets are one of the best sources for believable demo data. If your team keeps seeing time zone mistakes, duplicate invites, missing approval steps, or imports with blank columns, put those cases into the seed set. You already know they create confusion. Use that knowledge.

Believable data also makes demos and training better. Fake names are fine, but the patterns should feel real. A training workspace should look like a small company actually used it: a few active users, one admin doing most of the work, stale tasks, uneven activity, and one failed handoff between teams. That gives people something to investigate instead of just something to click through.

Good seed data creates the right kind of friction. It should make someone ask, "Why is this record here?" or "What happens if I reopen this account?" Those are the moments when hidden product issues show up.

Choose the workflows that matter

Start with the moments where a deal stalls, a task gets stuck, or a new user gets confused. That is where seed data earns its keep. If you try to cover everything at once, you usually end up with a lot of records and very little signal.

A good first pass looks at what buyers, admins, and support staff do most often. In a SaaS product, that usually means the path from account setup to the first real task, then the edits and changes people make after that. Think less about every individual screen and more about the sequence of actions that must work together.

A small set of workflows is usually enough to start:

1. Creating an account and finishing setup
2. Editing records after the first save
3. Sending something for approval and handling a rejection
4. Viewing reports after weeks or months of activity
5. Reopening old items that already have notes, tags, or status changes

Support tickets are a strong guide here too. If your team hears the same complaint every month, seed that path first. Problems rarely hide in the clean happy path. They show up when someone edits an unfinished record, when an approver sends it back with comments, or when a report includes missing fields and odd date ranges.

Setup, editing, approvals, and reporting deserve extra attention because they pull on different parts of the product. Setup checks defaults, permissions, and required fields. Editing shows whether old data still behaves after changes. Approvals expose status rules and notifications. Reporting tells you whether the system still makes sense after lots of small actions pile up.

A focused seed set beats a giant one. Four or five well chosen workflows can catch more problems than fifty random scenarios. I have seen teams find more issues by seeding one customer account with failed imports, duplicate contacts, stale invoices, and a rejected approval than they found in weeks of clicking through a polished demo.

Once those flows are solid, add more edge cases around them. Go deeper before you go wider.

Build the seed set step by step

Start small. Seed data gets better when it copies real work, not when it tries to model every record your product can hold. Pick the few workflows people touch every day and build around those first.

Begin with user roles. Most products only need a short cast to feel real: an admin, a manager, a regular staff user, and maybe a brand new account with almost no setup. Those roles create different views, permissions, and mistakes. That is where a lot of product issues show up.

Then map the records each role needs before they can do anything useful. If a support agent needs tickets, customers, tags, and saved replies, seed those together. If a manager needs reports, seed old records, missing fields, and awkward date ranges so the report does not look perfect by accident.

A simple process works well:

1. Pick three to five user roles that match real accounts.
2. List the records each role needs to finish one full task.
3. Define what normal data looks like and what messy data looks like.
4. Generate the same records the same way every time.
5. Wipe, reseed, and retest after each workflow change.

The messy part matters. Write rules for duplicates, unfinished records, expired items, odd dates, empty optional fields, and one or two broken relationships your app should handle without falling apart. Good seed data for QA should make screens look slightly irritating, because real databases usually do.

Keep generation repeatable. If one person runs the seed script on Monday and another runs it on Friday, both should get the same users, the same record counts, and the same weird cases. Fixed names, fixed dates, and stable IDs make bugs easier to spot and much easier to discuss.

Finally, treat reset as part of the workflow, not cleanup. When the team changes a process, wipe the data, rerun the seeds, and click through the path again. If the seed set only works once, it will fail when you need it most.

A simple example from a SaaS product

Imagine a small B2B SaaS product for invoicing and customer onboarding. A useful seed set has two accounts. One is brand new and clean. The other looks like a real account after months of rushed work.

The clean account helps sales show the happy path. It has one admin, two active users, a complete company profile, and a first invoice paid on time. A buyer can understand the product quickly.

The messy account shows where the product gets awkward. Give it duplicate contacts like "Maria Chen" and "M. Chen" with the same email entered twice. Add two overdue invoices, one failed payment retry, and a canceled add on that still appears in billing history. Set the onboarding checklist to 80% complete, then leave one required field blank, such as the billing contact phone number or tax ID.

That one blank field often exposes weak spots fast. The setup page may keep asking the user to finish onboarding without saying what is missing. An alert may fire every day. The export may include an empty column header or shift values into the wrong field. Filters may show one duplicate contact on the screen but two in the CSV.

QA can learn a lot from a quick pass through this account:

• Open the dashboard and confirm overdue invoice alerts appear once, not five times.
• Filter contacts by email and check whether duplicates remain visible.
• Try to finish onboarding and see whether the product explains the missing field clearly.
• Export invoices and contacts, then compare the file with what appears on screen.

This kind of seed data does two jobs at once. Sales can still walk through a smooth account. QA can switch to the messy one and test the parts that usually fail in real life, before a buyer or customer hits them first.

Keep seed data safe and easy to reset

Copying production data into a demo or QA system is a bad habit. One real email address, invoice note, or support comment can slip through and create a privacy problem fast. Fix that at the source, not by hand at the end.

Remove real customer details from every record type, not just the obvious ones. Teams usually scrub users and accounts, then forget notes, file names, message threads, exports, and audit logs. Those hidden fields often contain the most sensitive details.

Names and companies should look believable, but they should also look clearly synthetic. If someone sees the data on a screen, they should know right away that it is fake. Labels like "Demo Clinic West," "Sample Parts Co," or "Test Account 204" work better than realistic local business names that could belong to an actual customer.

A simple naming rule keeps everyone consistent:

• Add a visible marker such as "Demo," "Sample," or "Test."
• Avoid real cities paired with realistic company names.
• Use fake phone numbers, tax IDs, and addresses in the same format every time.
• Keep internal comments generic and free of personal details.

Reset speed matters more than many teams expect. QA should be able to start over in minutes, not spend half a day cleaning records and reloading files. If a tester cannot get back to a known state quickly, they stop retesting edge cases and miss bugs that only appear on the second or third pass.

Treat reset scripts like part of the app. Store seed versions with the same codebase as migrations, fixtures, and setup scripts. When the schema changes, update the seed set in the same pull request. That keeps demo data usable instead of letting it drift out of date.

The safest setup is usually simple: one command to wipe, reseed, and verify the environment. If that same command restores files, queues, and test credentials, new teammates can start with clean data on day one.

Common seed data mistakes

Most seed sets fail in predictable ways. The problem is rarely a lack of effort. Teams spend time on demo data, then fill the system with records that look neat and complete instead of records that behave like real customer data.

The most common mistake is seeding only happy path records. Every account has a full profile. Every order has all fields filled in. Every project is active and assigned correctly. That makes demos look smooth, but it hides the bugs people hit all the time, like unfinished onboarding, canceled subscriptions, duplicate contacts, or tasks with no owner.

Another problem shows up after a few releases. Teams forget old records created before recent schema changes. Real systems keep history. A customer who signed up two years ago may still have data shaped by an older version of the app. If your seed set contains only fresh records, you miss the strange breaks that happen when old and new data meet in one workflow.

Too much random data causes a different problem. A giant script creates fifty thousand records with random names, dates, and values, and nobody knows what any of it is for. QA cannot tell which record should trigger a refund edge case. Sales cannot find the account that should show a failed onboarding flow. Once the data loses meaning, testing slows down.

Teams also stop updating the seed set after the product changes. A new approval step appears. Roles change. Billing rules change. The app moves on, but the demo data stays frozen. Then demos and QA run against an older version of reality, and issues slip through because nobody tested the current paths.

A better seed set is smaller and more intentional. Give records names people can recognize, keep a few older records around, and add messy cases on purpose. One account with missing setup details can teach you more than a thousand random ones.

If you want seed data to catch real problems, treat it like product code. Review it, trim it, and update it whenever the product changes in a way users will notice.

Checks before you use it

A seed set is ready only when someone new can use it without a guided tour. Ask a tester who did not build it to log in, click around, and explain what they think each account is doing. If they stop to ask why an order is stuck or who owns a project, the data probably needs better names, notes, or relationships.

State coverage matters more than row count. A good set shows the normal path, but it also includes work that failed halfway, records waiting on approval, expired subscriptions, canceled invoices, duplicate contacts, and old accounts with messy history. Teams catch problems when the app moves between states, not when every screen shows a neat success case.

Run the seed twice in a clean environment. The second run should produce the same result as the first, with the same IDs or predictable references, the same totals, and no duplicate junk. If one run gives five overdue invoices and the next gives seven, debugging gets slow fast.

For demos, avoid empty screens. A sales or onboarding account should look lived in. Give it a few months of activity, some recent actions, some older records, one or two abandoned items, and a user who has changed settings before. That feels real. It also shows whether filters, timelines, summaries, and notifications behave the way customers expect.

A short review is usually enough:

• A new tester can tell what each account, user, and record is for.
• The data includes completed, failed, and unfinished work.
• Running the seed again gives the same result every time.
• Demo accounts show believable history instead of blank dashboards.

One extra check saves pain later. Open the app with a non technical person beside you and ask what looks odd. They often spot fake patterns faster than engineers do. That is especially true with demo seed data, where a perfect dataset can hide the exact issue a buyer will hit in the first few minutes.

What to do next

Pick one person to own each seed set. When nobody owns it, the data gets stale fast. One owner can approve changes, remove dead records, and keep the setup script working after product updates.

Treat seed coverage as release work, not cleanup. After every release, spend a short block of time checking whether the current data still matches your most important demo, QA, and onboarding paths. New fields, permissions, and billing rules can break realistic workflows long before anyone notices.

A simple review loop works well. Compare the latest release notes with your seed scenarios. Ask QA which bugs were hard to reproduce because the data was too clean. Ask sales where prospects hit questions the demo cannot answer. Ask support which messy customer states show up often but never appear in test accounts.

Those conversations matter because fake looking data usually comes from missing context, not missing rows. Sales sees awkward demos. Support sees messy histories. QA sees edge cases scripts skip. Put those views together and the seed set gets much closer to real life.

If you change only one thing this week, rebuild one seed set around a single messy workflow. Try a late payment, an unfinished onboarding flow, a user with the wrong role, or a duplicate account. Small fixes like that catch issues earlier and make demo data far more useful.

If your team wants a second opinion, Oleg Sotnikov at oleg.is works with startups and small companies as a fractional CTO and advisor. A short workflow review can help you map the parts of the product that look fine in a clean demo but break once the data starts behaving like real customers.