FROM AI IDEA TO BUSINESS SOFTWARE
Can we reuse the AI code, or do we need to rebuild?
Assess the parts before judging the whole.
AI-generated code does not automatically need rebuilding. Assess whether it is secure, understandable and changeable for the needs you actually have. Keep working parts, improve bounded problems and rebuild where specific obstacles justify it. Even a prototype whose code is replaced can provide valuable understanding of user needs.
Separate code quality from what you have learned
A prototype may demonstrate the right workflow while lacking a sustainable data model. Screens, user tests, terminology and decisions may still be useful when the technology changes. Make two lists: behaviour to preserve and technical parts needing review.
Ask for an assessment with specific evidence
| Option | When it may fit | Evidence to request |
|---|---|---|
| Keep | The component meets the need and can be verified and changed in a controlled way. | Which tests and checks support the assessment? |
| Improve | The issue is bounded, such as a duplicated rule or unclear module. | What changes, what is affected and how is working behaviour protected? |
| Rebuild a part | A central design prevents required permissions, data flows or changes. | Why is a smaller fix insufficient, and how will data and functionality move? |
| Investigate first | Source, data or dependencies are not yet sufficiently understood. | Which short investigation is needed before an estimate can be trusted? |
Make the smallest justified change and preserve what already works.
Review code and database together
Where are business rules implemented? Does the same term mean different things in different tables? Can database changes be tested and applied without losing records? Also review dependencies, licences and portability. Neat-looking code is not enough if the underlying information is inconsistent.
Avoid two expensive shortcuts
- “It works, so leave it alone.” This may leave real security or change problems unresolved.
- “AI built it, so start again.” This may discard working parts without a change in need.
Choose the smallest justified change
Ask the team to compare alternatives, uncertainties and what the work will enable. If a component needs replacing, plan tests, any data migration, transition and recovery. A rewrite should solve a named problem within a clear boundary, rather than add the whole wish list.
PRACTICAL TEMPLATE
Copy: a decision per component
Use the headings as a starting point for your conversation. Leave secrets and customer records out of the document.
Component and the need it supports: Specific issues and evidence: Options: keep / improve / rebuild / investigate: Rationale and explicit exclusions: Effects on data, tests and transition: Owner, estimate with uncertainties and next decision:Download template (.txt) ↓
Common questions
Does rebuilding mean the prototype was wasted?
No. A tested workflow, clearer needs and documented exclusions can be valuable even if some code is replaced. Separate the value of learning from code reuse.
Can you estimate the cost from the demo alone?
A demo shows behaviour and scope, but a credible technical estimate may require access to code, database and integrations. Ask for assumptions and uncertainties to be explicit.
Sources and method
The review structure, examples and templates are Miller Development’s practical recommendations, informed by Sven Miller’s description of our approach. The references explain related principles; they do not validate these templates or certify a solution. Platform features and terms can change. This guide does not replace a review of your specific system.
OWASP ASVS provides a framework for technical security requirements and verification.
MILLER DEVELOPMENT
Want help taking the next step?
We help prioritise business value, review AI-built solutions and develop secure, stable systems integrated into your business. The next step may be a small test, a technical review or a bounded first delivery.
Talk to us ↗