Keep your test data away from real users - shippingszn launch readiness

Two databases: one to mess around with while you build (development), one that holds your actual users' actual data (production). They should never touch each other. Most modern builders and hosted database services (Replit, Supabase, Neon, PlanetScale) set you up with both automatically when you publish.

If you point a half-broken in-progress feature at the real database, you can corrupt or wipe real user data with one bad query. If you copy real user data into your dev environment, you've taken a privacy obligation and made it more likely to leak. Keep them apart.

The shippingszn CLI includes automated checks for this launch-readiness control.

The Launch Fix Kit keeps scan-specific findings, file and line evidence, AI-builder punch-list tasks, and verification steps tied to the paid report.

Know which is which: the database in your workspace is dev. The one your published app uses is prod.
Never paste production database credentials into your dev workspace.
When testing destructive features (delete account, bulk update, mass email), only test against dev data.
If you ever need a slice of prod data for debugging, scrub names, emails, and any personal info first.
Read your platform's docs on production databases so you know how to push schema changes (new tables, renamed columns) safely. Most have a one-page guide — the link below is Replit's, as one example.

Run the scanner | Unlock Launch Fix Kit

Canonical URL: https://shippingszn.com/i/dev-prod-data/