From a Claude Code or Codex MVP to production

Claude Code and Codex can read and edit project files, run commands and tests, and help build working software. With direction and review, they can help a founder turn a partly defined idea into screens, database-backed flows, and a prototype that users can try before every product decision has been settled.

That work can have lasting value. A prototype is not automatically “throwaway” because AI helped build it. It may contain product decisions, useful interface work, evidence from users, and a sharper definition of the business need.

But a prototype that works in a demo has not, by itself, demonstrated that it is ready to carry customer data, money, operational decisions, or the daily work of a business. The useful question is therefore not:

Should we ship it as-is, or rewrite everything?

The useful question is:

What did we learn, what is already sound, what needs strengthening, and where would keeping the current foundation create more risk than value?

The answer requires inspection, not ideology.

Start by separating product evidence from engineering evidence

An MVP can create two different kinds of evidence. The first is product evidence:

• Which user has the problem?
• Which workflow matters enough for them to try?
• What do they understand without explanation?
• Where do they hesitate or abandon the flow?
• Which exceptions appeared only after realistic use?
• What are people actually willing to change in their existing routine?

The second is evidence about the technical foundation:

• How are data and permissions modeled?
• Where do business rules live?
• How are errors, retries, and partial failures handled?
• Can important behavior be tested repeatedly?
• Can another developer understand and safely change the system?
• Is production activity visible enough to support users when something goes wrong?

A prototype can provide strong product evidence while still offering weak evidence that its technical foundation is production-ready. For this assessment, treat product validation and production readiness as separate questions.

What can often be kept

Even when the implementation needs substantial work, assets worth assessing for reuse include:

• User and business learning: interviews, test notes, rejected assumptions, and the language users naturally employ can explain why the product is shaped as it is.
• The workflow: a complete tested flow can document decisions, required information, observed exceptions, and places where users need help.
• Product and screen decisions: navigation, terminology, hierarchy, and interaction ideas may remain useful even if underlying code changes.
• Data and integration knowledge: realistic samples, API constraints, and observed vendor behavior can reduce rediscovery, provided credentials and personal data are handled safely.
• Parts of the code: components, schemas, prompts, tests, or adapters may be sound enough to keep. AI authorship establishes neither quality nor safety; the code must be read, run, and tested.

Four decisions—not one

For this article, we classify each part of the product into four practical categories:

1. Keep: review and tests show that the part is understandable, appropriately designed, and proportionate to its risk.
2. Strengthen: the design is useful but needs permission checks, validation, tests, logging, failure handling, or documentation.
3. Replace: a component such as authentication, payments, storage, or an integration should move to a better-supported implementation.
4. Rebuild: the foundation cannot responsibly support its intended use—for example, important rules are scattered through prompts and interface code, operational ownership is unclear, or small changes repeatedly break unrelated behavior.

These decisions can coexist in the same product. A team might keep the interface, strengthen the data model, replace authentication, and rebuild one critical workflow.

What a production assessment should inspect

The depth of the review should be proportionate to the potential impact of failure. An internal experiment and a system handling financial, health, or operational records deserve different levels of assurance. A baseline assessment can cover:

• Ownership and access: code, hosting, domains, databases, vendor accounts, secrets, and the business’s ability to operate when one person is unavailable.
• Identity and permissions: whether access is checked on every request in server-side logic and, where appropriate, at the database layer—not merely hidden in the interface.
• Data integrity: duplicate submissions, partial failures, and whether critical state changes follow explicit, testable rules and controls rather than unconstrained LLM output.
• Reliability and recovery: visible failures, safe retries, monitoring and alerts, a backup or recovery plan appropriate to the data, and evidence that can explain an incident.
• Maintainability: clear locations for important rules, reproducible builds and deployments, and automated protection for central flows.
• Cost and dependency limits: usage-based costs, quotas, latency, and failure behavior for models, browser automation, media, email, and external APIs.

For AI-native systems, document what an agent may read, which tools it may call, which actions it may propose or execute, and which actions require human approval.

A practical assessment process

The review does not need to begin with a large specification exercise. A useful sequence is:

1. Run the product as a user. Record the core flow, exceptions, and known failures.
2. Map the system. Identify the codebase, data stores, external services, environments, and account ownership.
3. Trace critical actions. Follow important state changes from the interface through APIs and data storage.
4. Run the existing checks. Verify whether the application builds, deploys, and passes whatever tests already exist.
5. Review high-risk areas. Focus on authentication, permissions, sensitive data, payments, agent actions, and irreplaceable business records.
6. Classify the parts. Keep, strengthen, replace, or rebuild—with a reason for each decision.
7. Plan in stages. Protect the most important behavior first, then improve or replace foundations without losing the validated product learning.

The output should be a decision document, not merely a list of code complaints. It should connect each technical issue to business risk, user impact, cost, and the next practical action.

Preserve learning while reducing uncertainty

Moving toward production does not require freezing product development for months. It does require changing the order of work.

First, make ownership and environments clear. Protect sensitive data and critical actions. Add repeatable checks around the workflows users have already validated. Then continue in small, reviewable releases with monitoring and a rollback or recovery path appropriate to their risk.

In this phase, a hands-on product and development team needs to do more than add coding capacity. It should understand the business process, assess which prototype decisions remain valuable, identify operational risks, and strengthen the foundation without erasing what the MVP taught you.

If you have a working prototype, the best first step is neither a sales pitch for a rewrite nor reassurance that everything is ready. It is an honest assessment of the product you have and the product the business now needs.

Sources and further reading

• OpenAI: Codex — current Codex software-development capabilities and workflows.
• Anthropic: How Claude Code works — Claude Code’s access to project files, commands, tests, and Git state.
• GOV.UK: Making prototypes — why prototype code and production code may require different standards.
• GOV.UK: Using moderated usability testing — observing people complete realistic tasks.
• NIST Secure Software Development Framework — risk-based secure software-development practices.
• OWASP Authorization Cheat Sheet — least privilege, permission checks, logging, and authorization tests.
• NIST Generative AI Profile — risk-tiering, evaluation, oversight, and deployment controls for generative AI.
• GOV.UK: Operate a reliable service — testing, monitoring, incident response, and proportionate reliability planning.
• DORA: Working in small batches — feedback, verification, and small-batch software delivery.

Related: Custom web applications built around real business workflows.

Have a working prototype? Discuss a prototype-to-production assessment.