Never Develop Without Seeded Data

Context

Working with a software team, we struggled on a user story review because we quickly hit a wall—edge cases didn't have data in the demo. The demo went well at first, then came to a cold stop because we couldn't review all of the acceptance criteria. It affected everyone: backend, frontend, and product owner.

During the demo, the simple feature test worked great. Once we went into the details of the acceptance criteria, however, things got difficult because we couldn't quickly show how edge cases worked. Instead, we had to painstakingly move the ticket back to review so the team could finish the ticket, and then start the review all over again. One edge case we couldn't test required folders with subdirectories—and we didn't have any set up.

So what did we do during the demo? We tried to create them on the fly. But because we needed 10 of them, it held up a team of 4 people on demo day. Clearly not feasible.

Friction like that makes things awkward and slows everyone down. The end result wasn't just a delayed feature—it was a drain on morale. The natural energy of the room decreased dramatically. Instead of showing things off and saying, "Look how amazing this is," it eroded into "Why doesn't this work?" Nobody wins in that scenario.

Lessons

Two key lessons came out of this experience.

First, seed your test data early—not just before demo day, but as you're developing the ticket. If you build the feature without the data to prove it works, you're setting yourself up for surprises when it matters most. Second, protect your micro-momentum. Demos build energy when each feature flows into the next; every stall kills that momentum and shifts the room from celebration to troubleshooting. Small preparation gaps create compounding friction that drains the team far more than the time it would've taken to set up properly.

How to apply at work

Use "Dev With Seeded Data" Sequence!

1. Pick up the user story and read through all acceptance criteria before writing any code.

2. Identify every data scenario you'll need to demonstrate—happy path, edge cases, empty states, error conditions.

3. Seed your test data immediately—before you start development, not after.

4. Build the feature with your seeded data already in place so you can validate as you go.

5. Test each acceptance criterion against your seeded data during development, not just at the end.

6. Do a dry-run demo with yourself or a teammate to catch any missing data gaps before the real thing.

7. Document your test data setup so the team can reproduce it or reset it if needed.

8. Demo with confidence—every acceptance criterion has data behind it, every edge case is ready to show, and micro-momentum stays intact.

The Payoff

When test data is seeded early, demos become celebrations instead of troubleshooting sessions. The product owner sees exactly what they asked for, the team feels proud of their work, and tickets close cleanly on the first review. But the real payoff is compounding.

Teams that protect their micro-momentum build trust—with each other and with stakeholders. Confidence grows. Friction disappears. The 20 minutes you spend seeding data upfront saves hours of rework, awkward silence, and morale repair on the backend.

You stop asking "Why doesn't this work?" and start hearing "When can we ship it?"