A custom application can work perfectly in a developer’s environment and still be unready for real users. Production readiness is the point where a team can explain how the application is deployed, monitored, supported, secured, and recovered—not merely demonstrate that its main screen loads.
For a small business, this does not require an enterprise bureaucracy. A focused review with the people who built the application and the people who will rely on it can expose gaps while they are still affordable to fix. The goal is evidence: a passing test, a documented decision, a known owner, or a restore that has actually been rehearsed.
Start with the business-critical journeys
Begin with the work the application must support. Write down three to five critical journeys in plain language, such as “a customer submits an order,” “an employee approves a request,” or “an operations lead exports a daily report.” For each journey, identify the expected result, the systems it touches, and what a user should do if it fails.
Test the complete path in a production-like environment, including authentication, validation, notifications, background processing, and any downstream integration. A unit test can show that one function behaves correctly; a journey test shows whether the business process completes. Include an unhappy path, such as a rejected payment, unavailable API, duplicate submission, or missing required field.
Confirm that environments and configuration are deliberate
List the environments used by the team and the purpose of each one. Development, test, staging, and production do not need identical infrastructure, but the differences should be known. Staging is most useful when it exercises the same important deployment steps, configuration shape, and dependencies as production.
Review how configuration is supplied. Environment-specific values should be separated from application code, and sensitive values should come from an approved secret store or protected deployment mechanism. Check that the application fails clearly when a required setting is missing. Also verify that diagnostic settings are appropriate: verbose development output should not quietly expose sensitive details in production.
Record the exact build or release version being reviewed. A repeatable build and a documented deployment path make it possible to answer a simple question later: what changed?
Protect data and practice recovery
Identify every production data store, including the primary database, uploaded files, queues, and any important configuration or encryption material. For each one, document how it is backed up, how long backups are retained, who can restore it, and where the restore procedure lives.
A backup policy is incomplete until a restore has been tested. Use a safe non-production destination and verify that the restored data is usable by the application. Record how long the exercise took, what was missing, and which steps need improvement. If the business has a recovery point or recovery time expectation, write it down as a decision rather than leaving it implied.
Be equally careful with data migration. A release that changes application code and data structure should have a tested sequence, a compatibility plan, and a clear response if the migration stops halfway. Do not assume that a deployment can simply be reversed after data has changed.
Make failures visible without making them noisy
Check whether the team can tell the difference between a healthy application, a degraded dependency, and a complete outage. A useful health check should cover the components that matter to a request, return a machine-readable result, and avoid exposing internal details to unauthenticated visitors.
Review logs for useful context: a correlation or request identifier, timestamp, operation, outcome, and safe error detail. Logs should help an operator trace a problem without copying passwords, tokens, or unnecessary customer data. Add alerts for conditions that need action, not every transient event. For example, a sustained failure in a payment or integration dependency may need attention; one temporary timeout may only need a retry and a record.
Test the alert path. An alert that reaches nobody, lacks an owner, or cannot point to a runbook is decoration rather than operational support.
Review access and the release path
List the people and services that can deploy, administer, or read production data. Remove stale access, use separate permissions for routine work and emergency changes, and confirm that service accounts have only the access their functions require. Make sure the application does not ship with test accounts, default credentials, debug endpoints, or unnecessary administrative routes enabled.
Then walk through the release process from a code change to production. Confirm that automated checks run before deployment, that a reviewer knows what is changing, and that the team can identify the artifact that was released. If a staging or pilot step exists, record what it proves and what it does not prove.
Define the rollback decision in advance. Some changes can be reverted by deploying a prior build. Others require a forward fix because data or external systems have already changed. The right plan depends on the application, but the decision should not be invented during an incident.
Assign ownership beyond launch day
Every production application needs an owner for technical decisions and an owner for business decisions. Document who receives alerts, who can approve a release, who communicates with users, and who coordinates recovery. Include a short support handoff with the critical journeys, dependencies, dashboards, runbooks, and known limitations.
Finish the review by separating findings into “must fix before launch,” “acceptable with an owner and date,” and “future improvement.” This keeps a small team from treating every enhancement as a launch blocker while still making risk visible. Revisit the checklist after a major change, incident, or change in business responsibility.
Production readiness is not a claim that an application will never fail. It is evidence that the team knows what the application depends on, can detect important failures, and has a practiced path to recover. That discipline gives custom software a better chance of remaining maintainable as the business grows.
Next step: Schedule a short consultation to identify the next useful improvement.