From prototype to production: the checklist

A prototype proves an idea works. Production proves it keeps working: on a busy Monday, after a bad update, when a provider is down, when the person who built it is on vacation. The gap between the two is mostly invisible in a demo, and AI tools have made it wider. You can now build something that looks finished in a weekend. The parts a demo doesn’t show still take deliberate work.

Whether you built the prototype yourself or you’re about to approve its launch, go through this list. Every “no” is a known risk you choose to fix or accept.

Accounts and ownership

• The code lives in a repository (the shared, versioned home of the code) under a business account, not a personal one.
• Hosting, domain, database and AI provider accounts belong to the business, and at least two people can log in.
• There is a list of every outside service the system uses, and who pays for each.
• The agreement says clearly who holds the rights to the code, and when they transfer.

Security and secrets

• No passwords or keys are written in the code or its history; they live in a protected settings store.
• Each person and each service has its own login, with only the access it needs.
• Users can see only their own data, and a test proves it.
• Forms and uploads reject bad input instead of trusting it.
• The prototype’s shortcuts are gone: test accounts, open admin pages, “temporary” settings.

Data and backups

• The database is backed up automatically, and someone has restored a backup to prove it works.
• You know where personal data is stored and how long you keep it.
• Changes to the structure of the data are scripted and repeatable, not done by hand.
• Test data is kept apart from real customer data.

Quality: tests and reviews

• Automated tests cover the paths that matter most: payments, login, who sees what, the main job.
• Tests run on every change, and a failure blocks the release.
• A second person reviews each change before it goes live.
• Someone new can set up the project from written steps.
• For AI features: a set of questions with known answers is checked before any prompt or model change.

Operations: monitoring, alerts and recovery

• Errors are recorded where a person will see them, not printed and lost.
• Alerts reach a named person when the site is down or errors spike.
• When an outside service fails, users see a clear message and nothing is lost; the system retries or waits instead of crashing.
• You can roll back: undo a bad release in minutes and return to the last version that worked.
• Releases are routine and automated, not a nervous manual ritual.

Costs and limits

• You know the monthly cost at today’s usage, and at ten times that.
• Spending limits and alerts are set on AI providers and cloud services.
• Each user and feature has sensible usage caps, so one runaway loop or bot can’t run up the bill.
• You know what happens when a free plan’s limits are reached.

People and documentation

• One named person owns the system after launch.
• A short document explains what the system does, where it runs and how to fix common problems.
• Prompts and AI settings are stored and versioned with the code.
• Support knows how to tell a real bug from a confused user, and where to report it.

How to use the list

Don’t try to tick every box before launch day. Sort the “no” answers into three groups: fix before real users arrive (security, backups, the money path), fix in the first month, and accept for now with a note. That last group is fine, as long as it is written down and someone owns it.

If the list is long and the launch date is close, that is the work our prototype to production service covers: we keep what works in what you built, and add what production needs.