Series: From Prototype to Production
From prototype to a production-ready application
A prototype answers one question: does the idea even work? An application an organisation relies on day to day has to answer seven more, questions nobody had to ask while it was still a prototype. Each one comes with its typical default setting and a check step for assessing where things actually stand.
Short answer
An application is production-ready when, beyond its function, it answers seven questions: who is allowed to do what, how the data evolves, where the keys live, what can be reconstructed, how operations work, how changes are shipped safely, and which legal framework applies. A prototype leaves these open, which is not a fault as long as it stays a prototype.
01
What does a prototype prove, and what does it not?
A prototype proves that an idea holds up: the interface works, the data flows, users understand the process. It does not prove that the application can be run securely, recoverably, changeably and lawfully. These properties do not appear as a side effect; they get built and checked on purpose.
Whether produced with Lovable, Bolt or Replit, written with Cursor or Claude Code, or assembled as an n8n workflow, prototypes come together fast today. The term vibe coding has taken hold for this way of working: software built in dialogue with a language model, without every line being read. It gets difficult once colleagues, customers or a business process start relying on the result. For app builders specifically, Built with Lovable, Bolt or Replit walks through the typical open points.
This shift rarely happens as a single decision; it tends to grow: first the team itself, then a second department, then real customer data. Where IT needs to take over such a tool, A department built an app helps. For automations and data tools there is From an n8n workflow or Streamlit script to an operable application.
- 01PrototypeDoes it even work?
- 02AssessmentCheck seven questions
- 03DecisionPatch up or rebuild
- 04HardeningClose open points
- 05HandoverCode, documentation, responsibility
- 06OperationsMonitor, back up, change
02
Why is it not enough that the application runs?
Because function and stability come from different places. Studies show that AI tools go together with faster but not more stable delivery, and that language models often pick insecure implementations. In a prototype, neither shows up, because nobody attacks it, nobody works on it in parallel, and an outage stops nobody.
Faster does not mean more stable. The DORA report State of AI-assisted Software Development (Google Cloud, 2025) surveyed almost 5,000 technology professionals, 90% of whom use AI at work. Unlike the year before, AI use now correlates positively with delivery throughput, but still negatively with delivery stability. The core thesis: AI amplifies what is already there.
The security flaw is often the default. In the 2025 GenAI Code Security Report (Veracode, 2025), over 100 language models solved 80 coding tasks in Java, Python, C# and JavaScript. Where a secure and an insecure implementation were both available, the models picked the insecure one 45% of the time and introduced vulnerabilities from the OWASP Top 10. Java came in at a 72% failure rate, and larger, newer models scored no better.
What studies show about the quality of AI-generated code covers the methodology and limits of these studies, and Vibe coding: where it helps, where it bites covers the underlying trade-off.
03
Which seven questions must a production application answer?
Identity and access, data storage and migrations, secrets and keys, traceability, operations, changeability, and the legal framework. For every dimension, a prototype carries a typical default that is fine for testing and becomes a risk in production. An overview covers all seven, and each gets its own closer look afterwards.
The seven dimensions at a glance
| Criterion | Typical prototype default | Concrete risk | Check step |
|---|---|---|---|
| Identity and access | Anyone logged in sees everything; roles exist only in the interface | Access to someone else's data bypassing the interface | Replay requests using a second test account |
| Data storage and migrations | Schema changed directly in the database, no migrations | States drift apart, changes cannot be reversed | Build an empty database from the repository |
| Secrets and keys | API keys in the frontend or in the repository | Outsiders use the keys, the data and the quota | Search shipped JavaScript and the Git history |
| Traceability | Console output with entire records, no audit log | Incidents cannot be reconstructed, logs full of personal data | Ask who changed a record and when |
| Operations | A platform's default plan, backups assumed to happen | An outage is noticed late, recovery never rehearsed | Restore a backup into a test environment once |
| Changeability | Changes go live directly, no tests, one environment | Any change can break something unrelated | Try rolling back a release |
| Legal framework | Data flows to external services, nothing written down | Approval fails even though the technology works | List data flows with purpose and recipient |
04
Identity and access: who is allowed to do what?
Default and risk: anyone logged in sees everything. Where roles exist, often only the interface hides a button, while the API behind it still answers every request. With Supabase, the database's row-level security decides whether the publicly shipped key reaches only allowed rows or entire tables. Anyone reading requests in the browser can then swap an identifier and pull someone else's records.
Check step: set up two test accounts with different roles, copy a request from the first account out of the browser's developer tools, and resend it while logged in as the second. If the record comes back, server-side checking is missing. Built with Lovable, Bolt or Replit explains the mechanism in app builders.
05
Data storage and migrations: how does the data evolve?
Default and risk: tables get created with a click in a dashboard or directly by a coding agent, with no migrations, meaning no versioned sequence of schema changes, and often with a single database serving both tests and real data. That makes it impossible to rebuild an environment identically, impossible to roll back a faulty change on purpose, and a renamed field can cost real data.
Check step: build an empty database purely from the repository. If that does not work without manual fixes, the migration history is incomplete. Recognising technical debt in AI-generated code describes how a disordered data model shows up as technical debt.
06
Secrets and keys: where do the credentials live?
Default and risk: the key for a language model or a payment service sits in the frontend code or in a .env file that made its way into the repository. Anything shipped to the browser is readable, and an exposed key can be used with its owner's permissions and at its owner's cost. Once committed, it stays in the Git history even after the file itself is deleted.
Check step: search the shipped JavaScript for terms such as key, secret or token, and search the Git history using the command shown here. Any key that was ever there gets replaced, not just moved.
git log -p --all | grep -inE 'api[_-]?key|secret|token|passw|sk-[a-z0-9]'Approving AI tools for a development team describes guardrails for keys and customer data in AI tools, and AI security covers the security questions of AI applications themselves.
07
Traceability: can what happened be reconstructed?
Default and risk: errors show up in the browser console or the terminal, then vanish. Where logging happens, entire records including email addresses often end up in the log, while nowhere is it recorded who changed a given record. If a user's details go missing, there is no trail, and the log itself becomes a data set that needs protecting.
Check step: an operations log shows what happened technically, an audit log shows who changed what and when at the business level. Try the test: who changed a given record yesterday, and what did it contain before? From an n8n workflow or Streamlit script to an operable application goes deeper into how automations surface failed runs.
08
Operations: who notices an outage, and how does the application come back?
Default and risk: the application runs on a platform's default plan or on the machine of whoever built it. Users are the ones who notice an outage, and the backup is presumably handled by the provider. The first real recovery then happens in an actual emergency, and with nobody named as responsible, operations hinge on one person's holiday schedule.
Check step: restore a backup into a separate environment once and start the application from it. Define how much data loss and downtime are tolerable (RPO and RTO, in the jargon) and who gets notified. Running an application in-house covers more on this, and From proof of concept to routine operation covers the handover documents needed.
09
Changeability: can the application be developed further without risk?
Default and risk: changes go live directly, in a single environment, with no automated tests. A coding agent rewrites entire files in response to a small request, and nobody compares what changed beforehand. Any change can then break something unrelated, the team starts avoiding changes, and the application freezes up. This is exactly where the DORA finding bites.
Check step: is there a test environment with its own database? Does a person read every change before it gets merged? Do tests cover the most important workflows? Can a release be rolled back without losing data? Recognising technical debt in AI-generated code and Approving AI tools for a development team go deeper.
10
Legal framework: is the application allowed to run this way?
Default and risk: inputs go to a language model's API, the database sits in whatever region was preselected, an analytics tool loads on first visit, and none of it is written down anywhere. The application works, but fails to get approval from data protection, IT security or procurement.
Check step: record every data flow as one line: which data, which service, which country, which purpose, and whether a data processing agreement is in place. Who is liable when AI-generated code causes damage? describes the general legal position, and Does AI in an application need to be labelled? covers labelling. On data protection there is GDPR-compliant AI, and for a first assessment the EU AI Act check.
11
Checklist: how production-ready is a prototype?
The checklist condenses the seven dimensions into 21 points, each answerable with yes or no and briefly justified. Open points are not a verdict on the prototype; they are the work list for the road to production. Only tick off what demonstrably holds true today, not what is planned.
Checklist
Production readiness checklist
The selection is for overview only and is not stored.
The order for closing open points
Whatever is exploitable from outside, first
Remove and replace keys from the client, enforce access rights server-side.
Clarify data flows
Before more real data comes in.
Backup and recovery
Changes to the data model are only defensible once the way back has been rehearsed.
Migrations, environments and tests
The foundation for controlled change.
Traceability and monitoring
Audit log, central error tracking and notification.
Handover
Documentation, responsibilities and briefing.
12
When is it fine for a prototype to stay a prototype?
When it processes no sensitive data, no business process depends on it, a person checks every result before it takes effect, and its end is foreseeable. In that case, hardening it has no payoff to justify it. What matters is that this line gets drawn on purpose and not crossed quietly.
- A small, known group of users: the team itself, not customers or other departments.
- No sensitive data: test or public data instead of personal data or trade secrets.
- No dependent process: if the application fails, the team keeps working the old way.
- A person before impact: results get read before they trigger an email, change a booking or reach a customer.
- A foreseeable end: the application answers one question and then gets switched off or replaced.
13
Patch it up or rebuild?
Patching up pays off when the code is under an organisation's own control, the data model reflects the business logic, access rights are enforced in one place, and someone who did not write the code can still read it. If several of these are missing, a rebuild is often the clearer path, with the prototype serving as a living specification.
A rebuild does not mean work gets lost: interfaces, workflows, copy and the edge cases already discovered are the best specification a development team can get.
Decision path
Patch it up or rebuild?
Answer the questions for the current state.
All questions and results as a list
- Does the complete source code sit in version control with direct access, not only through a platform?
- Yes, continue with: Does the data model cleanly reflect the business concepts, for example customer, order and invoice as their own tables?
- No, only inside a platform, continue with: Can the code and the database schema be exported completely from the platform?
- Can the code and the database schema be exported completely from the platform?
- Yes, continue with: Does the data model cleanly reflect the business concepts, for example customer, order and invoice as their own tables?
- No or unclear, Result: Clarify portability first
- Does the data model cleanly reflect the business concepts, for example customer, order and invoice as their own tables?
- Yes, continue with: Are access rights enforced in one central place, on the server or in the database?
- No, continue with: Does it already hold real data that needs to carry forward?
- Does it already hold real data that needs to carry forward?
- Yes, Result: Sort out the data model first
- No, Result: Lean towards rebuilding, using the prototype as a specification
- Are access rights enforced in one central place, on the server or in the database?
- Yes, continue with: Can someone who did not write the code follow a typical workflow through it?
- No, continue with: Can access checking be consolidated into one place without rebuilding every page?
- Can access checking be consolidated into one place without rebuilding every page?
- Yes, continue with: Can someone who did not write the code follow a typical workflow through it?
- No, Result: Rebuild, carrying over the interface and workflows
- Can someone who did not write the code follow a typical workflow through it?
- Yes, Result: Lean towards patching up
- No, continue with: Does the business scope stay roughly what the prototype already shows?
- Does the business scope stay roughly what the prototype already shows?
- Yes, Result: Patch up with a targeted rebuild
- No, it grows significantly, Result: Rebuild, carrying over the interface and workflows
- Result: Clarify portability firstAs long as the code is not under direct control, every decision hangs on the platform. Worth discussing: export paths, whether the database and login can be taken along, and what has to be rebuilt on a switch.
- Result: Sort out the data model firstReal data in a poorly fitting model turns every rebuild into a data migration project. Worth discussing: a target model, the path existing data takes to get there, and only after that the rest of the code.
- Result: Lean towards rebuilding, using the prototype as a specificationWithout a workable data model and without existing data, a rebuild is usually the more straightforward path. Worth discussing: which workflows and edge cases the prototype demonstrates, and which architecture covers the seven dimensions from the start.
- Result: Rebuild, carrying over the interface and workflowsScattered access logic or fast-growing scope can easily turn patching up into a patchwork. Worth discussing: what carries over directly, such as components and copy, and what gets restructured.
- Result: Patch up with a targeted rebuildThe foundation holds, but the code is hard to read. Worth discussing: which areas get made readable first, which tests come before that, and which checklist points remain open.
- Result: Lean towards patching upCode, data model and access rights form a workable foundation. Worth discussing: which checklist points remain open and in what order they get closed.
Both paths end with a handover that includes source code, documentation and named responsibility. Having a prototype developed further covers the questions for choosing outside support, including when no external provider is needed at all.
14
Which article in the series fits a given question?
Liability and the legal position
Law
Approval from IT
Takeover
A department built an app: what IT checks before taking it over.
App builders
Tools
Built with Lovable, Bolt or Replit: the typical open points, self-checkable.
The evidence
Studies
What studies show about the quality of AI-generated code, along with their limits.
Handover into routine operation
Handover
From proof of concept to routine operation: the documents needed on handover day.
Software estimates
Effort
How accurate can an estimate be?: the estimation range and what narrows it.
Technical debt
Maintainability
Recognising technical debt in AI-generated code, even without a developer role.
Running it in-house
Operations
Running an application in-house: monitoring, backups, updates.
AI labelling
Transparency
Workflows and scripts
Automation
From an n8n workflow or Streamlit script to an operable application
Guardrails for AI tools
Team
Approving AI tools for a development team: access rights, review, secrets.
Choosing a provider
Selection
Having a prototype developed further: questions to ask providers, and when none is needed at all.
iiterate Technologies GmbH, based in Adenau, develops AI applications and custom software, from architecture through implementation to operations, on a client's own infrastructure or in EU hosting, with source code and documentation handed over. Services gives an overview.
All articles in the series
-
-
-
-
04 The business unit built an app: what IT checks before taking it over A business-unit app is heading into production: which points IT settles before approval, which can follow later, and how a handover document is built. -
05 From proof of concept to routine operation: the technical handover What a proof of concept needs before routine operation: six handover artefacts, and the difference between working and operable. -
06 How accurate can a software estimate be? The estimation range Why an early software estimate is a range, which milestones narrow the estimation range, and when a fixed commitment becomes justified. -
07 Running an application in-house: what day-to-day operations involve What running an application in-house involves, from monitoring to recovery, and when managed operation or a platform fits better. -
-
-
-
Frequently asked questions
When is software production-ready?
When, beyond its function, it demonstrably answers who is allowed to do what, how data changes in a controlled way, where keys live, how events can be reconstructed, how outages get noticed and fixed, how changes are shipped safely, and on what basis data flows. That extends to operations, documentation and responsibility too.
What is the difference between a prototype, an MVP and a product?
A prototype checks whether an idea works, and is allowed to take shortcuts to do that. An MVP, a minimum viable product, is already used by real users and therefore needs the fundamentals of security and data handling. A product is additionally built for lasting operation, further development and handover to other people.
Is AI-generated code inherently insecure?
No. Studies such as the 2025 Veracode report do show that language models often pick insecure implementations even when a secure one is available. The problem lies less in the code's origin than in the missing review. Generated code that gets read, tested and checked against the seven dimensions can run just as reliably as code written by hand.
Can an application keep being used while it is being hardened?
Often yes, if the order is right. Gaps exploitable from outside get closed first: keys in the client and missing server-side access rights. Backups, migrations and tests follow after that. It gets difficult when the data model needs a fundamental change while new data keeps arriving daily; then the data migration needs a plan of its own.
Does the assessment need an external provider?
No. Many checklist points can be verified directly with the browser's developer tools, the repository and a conversation with the people involved. External support helps most where in-house experience with operations, security or data models is missing, or where an independent assessment is wanted.
Read on
Sources
- 01 Announcing the 2025 DORA Report: State of AI-assisted Software Development Google Cloud, 2025 · cloud.google.com
- 02 State of AI-assisted Software Development 2025 DORA, Google Cloud, 2025 · dora.dev
- 03 Insights from 2025 GenAI Code Security Report Veracode, 2025 · veracode.com
- 04 AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks (Pressemitteilung) Veracode, Business Wire, 2025 · businesswire.com
- 05 2025 GenAI Code Security Report Veracode, 2025 · veracode.com
- 06 Cybersicherheitsrecht: NIS-2-Umsetzungsgesetz ab morgen in Kraft Bundesamt für Sicherheit in der Informationstechnik (BSI), 2025 · bsi.bund.de
- 07 Transparency obligations under Article 50 of the AI Act EU-Kommission, 2026 · digital-strategy.ec.europa.eu
- 08 Cyber Resilience Act: Reporting obligations EU-Kommission, 2026 · digital-strategy.ec.europa.eu
- 09 Liability for defective products EU-Kommission, 2026 · single-market-economy.ec.europa.eu
Let us talk about your project
Whether it is a prototype, an internal tool or an AI application: describe briefly what you are building or want to take into production.