A prototype only needs to work long enough to prove an idea. A production app needs to keep working when real customers arrive, data changes, integrations fail, and someone deploys the wrong thing on a Friday afternoon.
That gap catches startups constantly. The interface looks finished, the core workflow works in a demo, and the team assumes the product is ready to launch. Then the first real users uncover missing access controls, fragile deployments, unhandled errors, and no way to recover lost data.
Production readiness is not about adding enterprise complexity to a young product. It is about removing the obvious ways the product can hurt the business.
1. Lock Down Authentication and Authorisation
Authentication confirms who a user is. Authorisation controls what that user is allowed to do. A surprising number of applications implement the first and assume the second will take care of itself.
Before launch, verify that:
- Every private route checks the user's session on the server
- Users cannot access another account's data by changing an ID in a URL or request
- Admin actions are enforced by backend permissions, not hidden buttons
- Password resets and email verification work from start to finish
- Sessions expire and refresh predictably
- Login, signup, and recovery endpoints have rate limits
- Service keys and admin credentials never reach the browser
If you use Supabase, Row Level Security should be enabled on every table exposed through the API. Each policy should be tested with at least two separate user accounts. Being able to retrieve the correct data is only half the test; you also need to prove that the wrong account cannot retrieve it.
2. Separate Your Environments
Development, preview, and production should not share the same database, API keys, or third-party accounts.
At minimum, use:
| Environment | Purpose | Data |
|---|---|---|
| Local | Individual development | Seeded or synthetic data |
| Preview or staging | Review and integration testing | Non-sensitive test data |
| Production | Real customers | Live data with restricted access |
This separation prevents a test script from emailing customers, deleting live records, or filling production analytics with development traffic. It also gives the team somewhere safe to test migrations and integration changes before release.
Keep environment variables in the hosting platform or a secrets manager. Do not commit .env files, paste secrets into issue trackers, or reuse production credentials locally.
3. Make Deployments Repeatable
A deployment should be a routine operation, not a sequence only one developer remembers.
The basic release path should include:
- A pull request or reviewed change
- Automated type checking and tests
- A preview deployment for visual and functional review
- A production deployment from the main branch
- A known rollback path if the release fails
Database changes need the same discipline. Store migrations in source control, apply them in a predictable order, and design destructive changes so old and new application versions can overlap during a deployment.
Avoid editing the production database manually unless it is an incident response measure. Manual changes are hard to reproduce, easy to forget, and usually become the cause of the next deployment failure.
4. Add Useful Monitoring
Monitoring does not mean buying an expensive observability stack. A small product needs a few reliable signals:
- Error tracking for uncaught frontend and backend exceptions
- Uptime checks for the public site and critical API routes
- Structured application logs with enough context to trace a failed request
- Alerts for repeated job failures and broken integrations
- Basic infrastructure metrics such as latency, error rate, and database capacity
Alerts should identify conditions that require action. If every minor warning sends a notification, the team will learn to ignore all of them.
Test the monitoring before launch. Deliberately trigger a safe error, fail a test job, and confirm that the right person receives a useful alert.
5. Plan for Integration Failures
Payment providers, CRMs, email services, and external APIs will eventually time out or return an error. Your app should expect that.
For every important integration, decide:
- What happens when the request fails?
- Is it safe to retry?
- Could a retry create a duplicate payment, email, or record?
- Is the failure recorded somewhere visible?
- Can a team member replay the operation after fixing the cause?
Background jobs should use unique identifiers or idempotency keys so a retry does not repeat an irreversible action. Critical webhooks should be stored before processing, acknowledged quickly, and retried through a queue rather than handled entirely inside one request.
6. Back Up Data - Then Test the Restore
A backup is only useful if it can be restored.
Confirm the database backup schedule, retention period, storage location, and restore process. Then perform a test restore into a non-production environment. Record how long it takes and what is missing.
The right recovery target depends on the product. A brochure site may tolerate a day of lost form submissions. A transactional platform may need point-in-time recovery measured in minutes. The important part is making that decision deliberately rather than discovering the backup limitations during an incident.
Also consider data outside the primary database: uploaded files, authentication records, automation history, configuration, and third-party systems may require separate recovery plans.
7. Check Performance Under Realistic Conditions
Your laptop is not a realistic customer device, and an empty database is not a realistic production database.
Test the main user journey on a mobile connection and a mid-range device. Measure the slowest API routes with production-like data. Check that large images are optimised, database queries use appropriate indexes, and pages do not fetch more data than they render.
Focus on the paths tied to revenue or retention:
- Signup and login
- Checkout or enquiry submission
- The primary dashboard
- Search and filtering
- File uploads
- Email or notification delivery
You do not need to optimise every millisecond before launch. You do need to know whether ten concurrent customers can exhaust a connection pool or turn a two-second query into a thirty-second timeout.
8. Cover the Operational Basics
The final checks are less technical but just as important:
- The domain, DNS, and SSL certificate are controlled by the business
- Billing alerts are enabled for hosting and API providers
- At least two authorised people can access critical accounts
- Privacy, terms, and consent flows reflect what the product actually collects
- Customer support has a clear path for reporting bugs
- There is a named owner for incidents and production access
- Analytics exclude team and development traffic where practical
Document the systems, owners, renewal dates, and recovery details in one place. This does not need to be a fifty-page runbook. A short, current document is more valuable than comprehensive documentation nobody maintains.
A Sensible Launch Standard
Production-ready does not mean perfect. It means the application has appropriate controls for its current risk.
A pre-revenue internal tool does not need the same architecture as a healthcare platform. But both need access controls, recoverable data, visible failures, and a repeatable way to release changes.
Launch when the important failure modes are understood, monitored, and recoverable. That foundation gives the team room to move quickly after launch without treating every new customer as an infrastructure experiment.