A prototype answers an important question: can this idea work? Production software must answer many more. Can it protect real data, handle failure, recover from mistakes, support concurrent users and remain maintainable after the original team moves on?

The gap is not a matter of adding a few tests before launch. It spans product scope, architecture, database design, security, operations and ownership. The same distinction is explored for AI initiatives in AI proof of concept versus production system.

Use this checklist to run a production-readiness review. Adapt the depth of each item to the system’s risk; an internal scheduling tool and a regulated payment platform should not face identical controls.

1. Confirm the product boundary

Before hardening technology, confirm what is actually going into production.

  • Are priority user journeys defined with acceptance criteria?
  • Are user roles and permissions agreed?
  • Are edge cases and failure outcomes specified?
  • Is the source of each important business rule known?
  • Are unsupported prototype features clearly excluded?
  • Is there an accountable product owner for launch decisions?

Avoid expanding the prototype screen by screen. Revalidate whether each function supports a real outcome. A smaller complete scope is safer than a broad system with partial controls.

2. Assess what can be reused

Do not assume prototype code must be discarded, but do not treat visible functionality as evidence of production quality.

Review the code, dependencies, data model, permissions and deployment approach. Classify components as:

  • suitable for production with normal improvement;
  • reusable after defined hardening;
  • useful only as a design reference;
  • unsafe or uneconomical to retain.

AI-generated or low-code components deserve the same evidence-based review as hand-written code. Check whether the team can understand, test, update and operate them. The comparison of AI-native development and vibe coding explains why a working interface is not sufficient evidence.

3. Define the target architecture

Document the system context and important component responsibilities.

  • Are domain boundaries and interfaces clear?
  • Does each critical dataset have an owner?
  • Are integration contracts versioned and testable?
  • Are failure, retry and timeout behaviors defined?
  • Can the chosen design meet availability and performance needs?
  • Are technology choices supported and maintainable by the future team?

Avoid adding distributed complexity without a clear need. A well-structured application with fewer moving parts is often the fastest safe route from prototype to production.

Record consequential architecture decisions and their trade-offs. Future maintainers need the reasoning, not only the final diagram.

4. Make the database production-ready

Prototype databases are optimized for speed of experimentation. Production data needs stronger controls.

  • Are relationships, uniqueness and required values enforced?
  • Are identifiers stable and independent of display values?
  • Is schema evolution handled by versioned migrations?
  • Are audit history and retention requirements covered?
  • Have representative volumes and query patterns been tested?
  • Are backup and restoration procedures verified?
  • Is sensitive data minimized and protected?

If the prototype contains real or imported data, profile its quality before migration. Define reconciliation checks and rollback consequences. Never rely only on a successful import message. Use the database modernization guide when the source data comes from a legacy application.

5. Establish identity and security controls

Security begins with the system design.

  • Is authentication appropriate for the user population?
  • Is authorisation enforced on the server for every protected action?
  • Is tenant or customer data properly isolated?
  • Are secrets kept outside source code and rotated?
  • Is input validated and output encoded?
  • Are dependencies scanned and updated through an owned process?
  • Are privileged actions recorded in meaningful audit logs?
  • Has the team modelled likely threats and abuse cases?

Separate development, test and production access. Give people and services the minimum permissions they need. If the system processes personal or sensitive information, complete privacy and security reviews before data is loaded.

6. Build a layered test strategy

Manual demonstrations prove only selected paths. Production confidence needs repeatable evidence.

Include:

  • unit tests for important rules and edge cases;
  • integration tests for databases and external services;
  • contract tests for interfaces that change independently;
  • end-to-end tests for critical user journeys;
  • permission and security tests;
  • migration and rollback tests;
  • performance tests against explicit thresholds;
  • recovery tests for plausible failures.

Prioritise by risk rather than chasing a single coverage percentage. A high number can still miss the transaction, permission or recovery behavior that matters most.

Tests should run automatically in the delivery pipeline, with failures preventing unsafe promotion.

7. Make deployment repeatable

Production deployment should be a controlled, reproducible procedure.

  • Is infrastructure defined and reviewed consistently?
  • Can the same application artifact move through environments?
  • Are configuration and secrets managed separately?
  • Are database changes ordered safely with application releases?
  • Can a release be rolled back or recovered forward?
  • Are release approvals proportionate and auditable?
  • Has the production procedure been rehearsed?

Reduce manual steps. A launch that depends on one engineer remembering a sequence is not operationally ready.

Feature flags can reduce release risk, but every flag needs ownership, safe defaults and a removal plan.

8. Add observability around user outcomes

Server uptime does not tell you whether customers can complete their work.

Define service indicators for important journeys, such as successful checkouts, completed file processing or response time for a core search. Add logs, metrics and traces that help operators diagnose failure without exposing sensitive data.

  • Are alerts actionable and connected to an owner?
  • Can the team distinguish user errors from system failures?
  • Are logs structured, protected and retained appropriately?
  • Are dashboards linked to agreed service expectations?
  • Has alerting been tested rather than only configured?

Monitor the first production releases closely and establish a clear route for user feedback.

9. Prepare operations and support

Software is not complete when development ends.

  • Who owns the service during and outside business hours?
  • How are incidents classified, escalated and communicated?
  • Are common recovery actions documented and tested?
  • Which suppliers or third parties need to be contacted during failure?
  • Are continuity and disaster-recovery expectations agreed?
  • Does the support team have safe tools and appropriate access?

Write runbooks for likely scenarios, but keep them concise and executable. Link them to monitoring and update them after incidents.

Our managed technology services can provide ongoing operation and maintenance after delivery where clients need continued ownership.

10. Review compliance and governance

Identify legal, contractual and industry requirements early. Confirm data-processing arrangements, retention, accessibility, intellectual-property ownership, licences and third-party terms.

Create an inventory of external services and know where important data is processed. If AI tools were used during development, verify how source code and client information were handled.

Record major risks, accepted exceptions and responsible owners. A readiness review should make residual risk visible to the person authorising launch.

11. Decide whether to launch

Use predefined launch criteria rather than relying on optimism after a busy final week.

A clear decision should state:

  • which acceptance criteria are met;
  • which known issues remain and their impact;
  • whether migration and rollback are proven;
  • whether operations and support are ready;
  • who accepts residual risk;
  • what evidence triggers rollback after release.

For higher-risk systems, run a limited release, selected-user pilot or parallel operation before full cutover.

RITE NRG’s software consulting and engineering service can assess a prototype, design the production target and deliver the transition without losing the learning already created.

Frequently asked questions

Can prototype code be used in production?

Yes, if review shows it meets the target architecture, security, testability and operational requirements. Reuse should be evidence based, not automatic.

How long does production hardening take?

It depends on prototype quality and system risk. An assessment should identify reusable components and hidden work before a schedule is committed.

What is the most commonly missed area?

Data and operations are often underestimated. Teams focus on visible features while migration, recovery, monitoring and ownership remain unresolved.

Is a security scan enough?

No. Automated scanning is useful, but architecture, authorisation, data flows and abuse cases need contextual review and testing.

Move from a working demo to a dependable service

A prototype is valuable evidence, not a finished production design. If you need an independent readiness assessment or an engineering team to take a prototype safely through launch, contact RITE NRG.