Keep prototype data out of production by recording what must be replaced, deleted or explicitly retained before publishing. A working preview is not evidence that its database contents belong in a live application.
Identify more than visible demo rows
Practical editorial advice: inventory seed scripts, fixtures, uploaded sample files, fallback responses and generated analytics totals as well as database records. A deleted demo row can return if an initialization process recreates it.
Use invented names and non-contactable placeholders rather than real customer information. For an Indian retail prototype, mark sample rupee totals and order references clearly enough that reviewers cannot mistake them for business activity.
Ask who may view the resulting data and who approves retention. These are privacy-review questions, not legal conclusions.
Build a mock-to-live register
For every data source, record:
- Location: database collection, fixture file, upload area or initialization process.
- Classification: synthetic, approved reference data or unresolved origin.
- Production action: replace, delete or retain with a written reason.
- Replacement dependency: what approved live input must exist first.
- Recreation risk: whether a seed or fallback can reintroduce it.
- Evidence: query result, code review or synthetic acceptance check.
- Approval: named owner and release status.
Keep database targets identifiable without recording passwords, tokens or connection secrets. A register entry saying “cleaned” is insufficient if nobody can say which environment was checked.
Hypothetical catalogue handover
Suppose a fictional Jaipur craft-store prototype contains 12 sample products, 5 sample orders and a startup script that inserts those orders when the database is empty.
The proposed register says: replace all 12 products with owner-approved catalogue records; delete all 5 orders; disable the demonstration order seeding for production. Retain a small set of approved category labels only after their owner signs off.
Evaluate an empty production-like rehearsal using synthetic inputs. Confirm that startup does not recreate the 5 orders, the catalogue reflects the approved replacement set and the order total begins at zero. This is an illustrative gate, not a claimed Replit test result.
Review publishing as a configuration boundary
Replit documents Publishing controls spanning app address, access choices, production database, monitoring, security and hosting settings. Its documented access choices include public, password-protected, workspace-only and invite-only. Those controls do not themselves establish that your data has been cleaned.
Stop if any record has unknown origin or a production initialization path still creates demonstration transactions. Next, resolve the register before approving the audience and database configuration.
If evaluating access offers, check the coding catalog for access format and saved terms before buying. Marketplace account/code/token offers are not proof of official subscription equivalence.
Sources and scope
Source material checked 29 October 2026; features/policies may change. Replit Publishing overview establishes the publishing-control scope and access choices. The register, cleanup sequence and rehearsal are editorial advice, not documented automatic data-separation guarantees.