Promote an AI-built prototype by treating it as a draft from an unknown contributor. Read the code that handles auth and data, strip demo shortcuts, vet every dependency, move secrets into configuration, put the repository behind review and CI gates, and only then deploy to a place that real users and real data can reach.
Why prototypes need a promotion step
A prototype answers one question: does this idea work? It was built to be fast, so it often has hard-coded test users, open routes, broad permissions and packages nobody chose on purpose. None of that is a moral failing. It becomes a problem only when the prototype quietly becomes the product because it already works.
NIST's Secure Software Development Framework describes a core set of high-level practices that can be added to any development life cycle model. The point for prototypes is simple: the practices do not apply themselves. Somebody has to decide that the prototype is now entering the life cycle.
The promotion checklist
| Step | What to do | Evidence to keep |
|---|---|---|
| 1. Name an owner | One person is accountable for the code after launch | Owner listed in the repo |
| 2. Read the risky parts | Review login, permissions, data access, file upload, anything that calls out | Review comment or PR |
| 3. Remove shortcuts | Delete test accounts, debug routes, disabled checks, sample keys | Diff of removals |
| 4. Vet dependencies | Check each package is needed, maintained and pinned | Dependency list with notes |
| 5. Move secrets | Keys live in the deployment environment, not the repo | Rotated keys |
| 6. Add gates | Protected branch, required review, CI checks | Branch rule settings |
| 7. Deploy to staging first | Test with synthetic data | Test log |
Do the steps in that order. Cleanup comes before gates because a gate that only checks a messy repo teaches the team to ignore failures.
Where AI-generated code needs a closer look
Reviewers tend to skim code that looks tidy. Slow down on four things: any route that returns data by an id the client sends, any place the code builds a query or a shell command from input, any package added without a clear reason, and any comment saying "for now" or "TODO auth". Those are the usual leftovers of a fast build.
On the access control point, OWASP's 2025 Top 10 keeps broken access control at the top and reports that every application tested had some form of it. A prototype with one demo user rarely tests that user A cannot read user B's records, so write that test before launch.
Assume the first deploy will be found
Public hosting makes a new URL discoverable quickly, so do not rely on obscurity. Keep the first production deploy behind your normal login or an allowlist until the review is done.
Where Safeguard fits
Safeguard can scan the repository for dependency issues and produce an SBOM, apply policies and gates on pull requests, and use reachability analysis to show which vulnerable code paths your app actually calls. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a failing check blocks the merge until the issue is fixed.
Quick check
Is a working demo enough to justify going live?
No. A demo shows the happy path for one user. Production needs tests for the unhappy paths, such as one user reading another user's data.
Who should own the prototype after launch?
One named person or team. Unowned code is the code that never gets patched.
Sources
Last reviewed: 19 October 2026.
