Is your AI-built app ready for production?
See what to review in security, database, backups, tests, monitoring, and deploy before putting real users on an AI-built app.
From prototype to production
AI built the first version. Engineering sustains the next ones.
A product can work very well during validation and still not be ready for users, data, payments, and continuous evolution. Origammi helps make that transition without throwing away what has already been built.
01
Why a prototype can work without being ready for production
Working and being ready for production are not the same thing. A prototype works when it does what was asked, at the moment it was tested, for the person testing it. Production is different: the system has to keep working with real data, users you don't know, misuse attempts, and rushed changes.
This isn't a criticism of building fast with AI. It's just recognizing that validating an idea and sustaining a product are two different problems, with different requirements.
02
What changes when users, data, and payments come in
While the product has no real users, security risks, infrastructure costs, and code fragility stay invisible — simply because no one but you is using the system, and volume is low.
Once users, data, and payments come in, each of those risks gains real consequence: a permission gap becomes someone else's data exposed; an unhandled error becomes a customer losing a purchase; a missing backup becomes a loss with no way back.
03
Security and authorization risks
- 01Permissions checked only in the interface, not on the server or database.
- 02Database access rules that let one user read another's data.
- 03Keys and secrets exposed in browser-shipped code or a public repository.
- 04Development and production environments sharing the same data.
04
Reliability, backups, monitoring, and rollback
- 01Automatic backups, genuinely tested — not just configured.
- 02Alerts when something important breaks in production.
- 03A safe way to undo a problematic release.
- 04Cost and infrastructure usage monitoring before it becomes a surprise.
05
Technical debt and regressions
Technical debt in an AI-built system has a particular trait: it piles up fast, because generating new code is cheap, and it stays hidden, because the code works right up until it doesn't.
The most common signal is regression: a small, seemingly isolated change breaks something that seemed unrelated. When that starts happening often, it's a sign the architecture is no longer keeping up with the product's growth.
06
When to keep using AI
Continuing to use AI makes sense to generate variations of something already well-structured, write tests for known behavior, or speed up mechanical tasks in code someone already understands.
AI alone tends to struggle with problems that require understanding the whole system — architecture decisions, root causes of recurring bugs, or choices that involve business trade-offs.
07
When to call an engineer
- 01The product is about to take on payments or sensitive data.
- 02AI has already tried fixing the same problem more than once, without success.
- 03No one is sure whether the data is protected.
- 04A small change broke something with no apparent relation.
- 05There's a sense that any change now is risky.
08
How to decide between keeping, refactoring, and rebuilding
Facing a quickly-built system, the question is rarely just "rewrite or not". There are five possible answers: keep what already works well; protect a fragile part with additional controls; refactor a specific section; replace one particular component; or rebuild when the evidence shows it's genuinely the cheaper path.
Rebuilding tends to be the most expensive answer, and the one most often offered by whoever just got acquainted with the project. It's worth being skeptical of any rewrite recommendation that arrives before a real investigation of what exists today.
09
How the Readiness Test works
The Production Readiness Test is a free self-assessment: questions about usage, security, reliability, and maintenance of your product. In a few minutes, you get a preliminary read on what most needs attention.
The result appears immediately, with no email required. It's a starting point — it does not replace a technical review of the code and infrastructure.
10
How the X-Ray goes deeper
When the free test points to real risk, the Production X-Ray goes deeper: a review of code, infrastructure, and critical flows, with the minimum access needed and representative samples for larger products.
The result is a prioritized risk map, recommended decisions, and a stabilization plan — not a generic best-practices list.
11
How the Stabilization Sprint works
When it makes sense to fix things, Origammi can also execute the priority items identified in the X-Ray — leaving a safer base for the product to keep evolving.
Go deeper
More code does not mean more delivery: where AI moves the engineering bottleneck
AI can speed up code production without shortening lead time. Learn where the engineering bottleneck migrates and what signals to investigate.
FAQ
Frequently asked questions
Do I need to stop using AI on my product?
Not necessarily. AI remains useful for generating variations, writing tests, and speeding up tasks in code someone understands well. The warning sign is when it starts retrying, reintroducing bugs, or losing context on important parts of the system.
Do I need a technical team to work with Origammi?
Teams of any size can benefit from the reasoning. Origammi mainly serves founders, small companies, and teams without a structured engineering org — you don't need a tech department for this to make sense.
Does every AI-built system need to be rewritten?
No. Rebuilding is one of five possible decisions (keep, protect, refactor, replace, rebuild), and tends to be the most expensive. The recommendation depends on evidence about the real product, not a general rule.