Something has changed about where software projects get stuck. The hard part used to be reaching a working version at all. Now a small team can have something that demonstrates well inside a fortnight, and the difficulty moves to a question nobody planned for: is this safe to put in front of customers?
The prototype works. It works in the demo, on the machine it was built on, with the dozen records someone typed in by hand. What it has never done is run unattended for a month with real data, real load, real people making mistakes, and real money attached to the outcome.
Productionisation is the work between those two states. It is largely invisible, it is mostly not new features, and skipping it is the most common reason a promising internal build never becomes something the business can depend on. For a structured approach to that work, see software productionisation.
Generated code optimises for the path you demonstrated
Ask an assistant for an order import and you get an order import. It works when the file is well formed, the network responds, the reference data exists, and nobody uploads the same file twice. Every one of those assumptions holds in a demo and breaks within a week of real use.
The gap is rarely in the logic anyone reviewed. It sits in the parts nobody asked for, because nobody thought to ask. What happens on the second attempt. What happens when a third-party API returns a 500 halfway through a batch. What happens when two people save the same record within the same second. What the system does about any of it when it has no way of knowing something went wrong.
None of this is a criticism of how the software was built. Fast assembly is genuinely valuable, and rewriting a working prototype from scratch usually throws away the one thing that made it worth having. The point is that speed produced a demonstration, and a demonstration is a different artefact from a system. The patterns worth checking for specifically are set out in reviewing AI-generated code.
Failure behaviour is the first thing to establish
Start with what the software does when something goes wrong, because that is the behaviour least likely to have been specified and most likely to be discovered by a customer.
Every external call needs a defined outcome for a timeout, a rejection and a partial success. Every job that processes a batch needs to be safe to run twice, because sooner or later it will be. Anything that writes needs to leave the data in a state someone can reason about after an interruption. These are ordinary engineering concerns, and they are almost never present in a first working version regardless of who or what wrote it.
The related question is what the software does about failure once it has one. Silent failure is worse than a crash, because a crash is at least reported. A batch that quietly skips nineteen malformed rows and reports success has created a data problem that will surface weeks later as an argument about stock figures.
Data, secrets and access
Prototypes are built with the permissions of the person building them, which is usually everything. That arrangement does not survive contact with production, and retrofitting access control is considerably harder than designing it in.
The checks are unglamorous and specific. Credentials belong in a secret store rather than a configuration file or a repository. Database users should hold the permissions the application actually needs. Personal data needs a defined retention position and a lawful basis, both of which are easier to establish before the data exists. Anything a customer can reach needs authorisation checked on the server, whatever the interface does or does not display.
Security is a governance question as much as a technical one, and the same reasoning applies here as it does to any other platform. Our note on security as a governance responsibility covers the oversight side of it.
Evidence that it works, and keeps working
A prototype is verified by someone using it and being satisfied. That verification does not survive the next change, which is the problem tests exist to solve.
Comprehensive coverage is not the goal and is rarely a good use of the budget. What you need is a small set of tests that fail loudly if the things the business cares about stop working: the calculation that determines what a customer is charged, the integration that keeps stock accurate, the path a user takes most often. Ten tests on the parts that matter are worth more than four hundred on the parts that do not.
Alongside that, the system needs to be able to tell you about itself. Structured logs with enough context to trace one transaction end to end. An alert when the error rate moves. A health check something can poll. Without these, the first indication of a problem is a phone call, and by then you are diagnosing from a customer's description rather than from evidence.
A deployment path you can reverse
Deploying from a laptop works until the day it does not, and the day it does not is usually the day it matters. What production needs is a repeatable path from source control to running software, an environment to try it in first, and a way back to the previous version that takes minutes rather than an afternoon.
The ability to reverse a release changes how a team behaves more than any other single control. When going backwards is cheap, people deploy smaller changes more often, and small frequent changes are the ones least likely to cause an incident. Holding that discipline as the team keeps building is covered in building with AI without losing control of the codebase.
Who signs it off
All of the above is a judgement exercise before it is a task list. Someone has to decide which risks are worth carrying, which are worth fixing now, and which can wait until the software has proved it is going to be used at all. That judgement is what separates a proportionate review from a checklist that stalls the project for a quarter.
If nobody in the business is positioned to make that call, an external review is the usual answer. Technical assurance exists for exactly this: an experienced engineer looking at what is about to go live, saying plainly what would concern them, and staying involved as the software changes.
The software your team built quickly is probably worth having. It just needs someone to check it before it starts carrying weight. If that is where you are, get in touch.
