From a Claude or Codex MVP to production

Claude, Codex, and other coding agents have changed what a founder can do before hiring a development team. You can clarify an idea, build real screens, connect a database, and put a working flow in front of users much earlier than was previously practical.

That work has value. A prototype is not “throwaway” merely because AI helped build it. It may contain months of product decisions, useful interface work, hard-won understanding of the users, and a much sharper definition of the business need.

But a prototype that works in a demo is not automatically 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 assets.

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 real use?
• What are people actually willing to change in their existing routine?

The second is 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 be excellent evidence of the first kind and weak evidence of the second. That is not a failure. It simply means that product validation and production readiness are separate decisions.

What can often be kept

Even when the implementation needs substantial work, valuable assets commonly survive:

• User and business learning: interviews, test notes, rejected assumptions, and the language users naturally employ explain why the product is shaped as it is.
• The workflow: a complete tested flow reveals decisions, required information, 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 vendor behavior 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 proves neither quality nor safety; the code must be read, run, and tested.

Four decisions—not one

A useful assessment classifies the product into four categories.

1. Keep: the part is understandable, testable, 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 safely support its intended use—for example, rules are scattered through prompts and UI code, 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 match the consequences of failure. A private experiment and a system managing financial, medical, or operational data do not need the same level of assurance.

At minimum, inspect:

• 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 enforced by the backend and database, not merely hidden in the interface.
• Data integrity: duplicate submissions, partial failures, and critical changes that must follow explicit rules rather than LLM improvisation.
• Reliability and recovery: visible failures, safe retries, appropriate backups, and evidence that explains an incident.
• Maintainability: one clear implementation of important rules, reproducible builds and deployments, and automated protection for central flows.
• Cost and limits: variable model, browser, media, email, and API costs; provider latency; and graceful behavior when a service is unavailable.

For AI-native systems, this also means defining what an agent may read, which tools it may call, what it may propose, 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.

The next phase should preserve learning while reducing uncertainty

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

First, make ownership and environments clear. Protect sensitive data and critical actions. Add repeatable checks around the workflows users already validated. Then continue product development in small releases that can be demonstrated, reviewed, and recovered.

This is also where a hands-on product and development team adds more than coding capacity. The team has to understand the business process, recognize which prototype decisions are valuable, identify hidden operational risk, and build the next 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.

Related: Custom web applications built around real business workflows.

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