The difference is responsibility, not visual polish
A polished screen can still be a fragile prototype. Production begins when real accounts, money, private data, store policies, and ongoing support become your responsibility.
Do not wait until the final week to think about those concerns. Choose the production foundation early, then add each responsibility when the feature that needs it enters the project.
Make the backend and data ownership explicit
Authentication
Use a proven authentication service or framework. Define session lifetime, recovery, account deletion, and what happens when access expires.
Authorization
A signed in user must still be limited to the records and actions they are allowed to access. Enforce this on the server or database, not only by hiding buttons.
Data lifecycle
Know what is stored, why it is needed, how long it remains, how it is backed up, and how a user can request export or deletion where required.
Migrations
Database changes need a repeatable path and a recovery plan. Test them against representative data before production depends on the new shape.
Give security its own pass
Security problems in AI built projects often appear because nobody asked for a security pass, not because an agent is incapable of implementing secure patterns. Make it an explicit workstream and repeat it when the architecture changes.
Keep secrets server side
API keys, service credentials, signing secrets, and private tokens belong in protected environment configuration and must never be committed or sent to the browser.
Validate every boundary
Treat form input, uploaded files, webhook bodies, URL parameters, and external API data as untrusted until they are validated.
Limit abuse
Add rate limits and sensible quotas to login, email, upload, expensive computation, and public API routes. Fail safely when a dependency is unavailable.
Harden the browser surface
Use secure cookies, restrictive response headers, a practical Content Security Policy, same origin checks for state changes, and no sensitive data in client logs.
Keep dependencies current
Security is maintained over time. Review advisories, patch dependencies, rotate exposed credentials, and repeat tests after meaningful changes.
Treat payments and external events as asynchronous
A successful checkout screen is not reliable proof that access should remain active forever. Use signed webhooks, idempotent processing, durable subscription state, and reconciliation jobs for payments. Apply the same thinking to app store purchases, email delivery, and third party callbacks.
Design what happens when an event arrives twice, arrives late, or fails halfway through. Those cases are normal production behavior, not rare exceptions.
Verify the journeys that can damage trust
Create and recover an account
Test a new user, an expired link, a returning session, logout, and the recovery path in the real production domain.
Complete and reverse a payment state
Test purchase, renewal, cancellation, failed payment, and entitlement expiry with the provider's supported test tools before opening sales.
Check permissions with two users
Try to access another account's records and privileged routes directly. The server must refuse even when a URL or request is modified.
Deploy and roll back
Know how configuration reaches production, how health is observed, and how to restore the previous version when a release fails.
Prepare support
Give users a clear contact path and give yourself the tools to find an account, inspect relevant status, and resolve a problem without exposing sensitive data.
Launch to a small real audience first
A small production release exposes issues that local testing cannot reproduce without turning every mistake into a public event. Watch the first real journeys, fix trust breaking problems first, and let observed use shape the next improvement.
Production is not a finish line. It is the point where decisions begin using real evidence instead of only assumptions.