One developer, one problem worth solving.

Why it exists

Test data is treated as an afterthought, and it shows.

Every team has the same story. A seed script nobody wants to own. A staging database restored from production because building something realistic was too much work. A test suite everyone calls flaky, which is really a fixture problem wearing a timing costume.

None of this is hard in an interesting way. It is just tedious, unglamorous, and permanently second in the queue. So it stays broken, and the cost gets paid quietly, one wasted afternoon at a time.

The approach

Read the schema. Fill it properly. Do not touch real data.

SeedQL introspects your database, works out the order tables have to be filled in so foreign keys resolve, and generates data that satisfies the constraints already declared in your schema. Runs are seeded, so the same seed reproduces the same dataset exactly.

No production row is read at any point. That is the part worth caring about: a copy of production sitting in six lower environments is a risk you are carrying whether or not anyone has noticed yet.

What being independent means

The honest version, both directions.

There is no support rota and no overnight cover. If you write in at 3am, nobody is awake. Features land when one person has time to build them properly, which is slower than a funded team and I am not going to pretend otherwise.

In exchange: when you report something, it goes straight to the person who wrote the code. There is no tier-one script and nobody asking you to clear your cache. Bugs get fixed by the author, usually the same week.

It also means claims stay conservative. Anything not built yet is marked as such rather than implied, and what ships is recorded in the changelog. If you find a place where the site promises more than the product does, that is a bug and I want to hear about it.