Launch readiness

The phase that was supposed to be “polish” grew into something more interesting: turning a working app into something you can responsibly charge strangers for. Most of it is invisible in the product, which is rather the point.

• Data durability. Encrypted Postgres backups every six hours to Cloudflare R2 (EU region), thirty-day retention, and, crucially, a rehearsed restore drill onto a separate machine that passed, plus a written migration-rollback runbook. A backup you’ve never restored is a hope, not a backup.
• A real staging environment. A second server mirroring production, exercised by the same uptime monitors and the CI pipeline, so deploys are rehearsed rather than performed live.
• Deploy-time guardrails. The fail-closed boot check that makes it impossible to run a dev auth-bypass on a production-tagged host.
• Legal and GDPR mechanics. Public terms, privacy, and sub-processor pages; data portability via account export; and the right to erasure, with the deletion path verified in a live drill (inside a transaction, rolled back) rather than assumed to work.
• Retention honesty. The LLM providers make conflicting claims about data retention, so those were reconciled into one dated, audited posture before publishing anything.

Then the security audit landed, and “polish” acquired a phase of its own. A full-repo review found a stack of Critical and High findings across auth and session integrity, secret handling, service-to-service authentication and billing atomicity: the kind of list that is uncomfortable to read and much better to read before strangers are paying you than after. Working through all of it gated the launch, and produced the internal-credential boundary the services now run behind.

Billing is live and enforced, the cost routing is running in production, and everything above is shipped and verified rather than planned.

The thing I underrated: none of this work is visible, none of it is fun, and all of it is the actual difference between a demo and a product.