A vibe-coded app: taking a prototype to a working system

A vibe-coded app is a program assembled through requests to a language model in plain words, without writing code by hand. For a company to actually use it, the app has to acquire six things a prototype does not have by definition. These are data storage inside a Russian environment, roles and access rights, exchange with accounting systems, protection against breakage on the next edit, logs with monitoring, and a named owner plus support after launch. A prototype shows that the task can be solved; a working system carries money, obligations and customer data.

Below is the operations route: what happens to an app after it has been assembled in an evening and started working. What exactly separates a demo from a system. Where the app's data lives and what part 5 of article 18 of the personal data law requires. How roles and permissions appear in the app. How it pulls counterparties and stock balances from CRM and 1C — the accounting and ERP platform most Russian companies run on. Why another request to the model breaks a scenario that used to work, and what fixes that. Who repairs the system on Monday morning, and by what signs a prototype has to be rewritten. The approach itself is covered separately — what vibe coding is and why business needs it; choosing a tool is in the comparison AI for vibe coding.

How does a prototype differ from a working system?

In short: by the number of people, the reality of the data, and what happens on the day of a failure.

A prototype serves one person — the one who assembled it. They know where to click, in what order to fill in the fields and what must not be done. The data in it is made up, and a failure costs a lost evening. As soon as a second employee sits down at the app, all three conditions stop holding at once.

The in-between state is the most dangerous one. The app is already working for real, because people use it, but by construction it is still a demo: no access rights, no action log, no backups. That state ends on the day someone opens another person's record or an employee leaves taking the hosting access with them.

Where does the app's data live, and what does 152-FZ require?

In short: on a generator platform the data sits on its infrastructure outside the country, while the law requires the database holding Russians' data to be kept in Russia.

Let us separate two questions that discussions tend to merge into one. The first is where the code goes at the moment of generation; that is a matter of trade secrets, and it is covered in the article on neural networks without data leaks. The second is where the working app's database physically sits. For a company, the second question is the costlier one.

The governing rule is stated directly:

When collecting personal data, including via the internet, the operator is obliged to ensure the recording, systematization, accumulation, storage, amendment and retrieval of the personal data of citizens of the Russian Federation using databases located on the territory of the Russian Federation — Federal Law 152-FZ, article 18, part 5, ConsultantPlus.

The platforms on which apps are assembled from a chat host the database themselves. While it holds test records, the requirement does not bite. It kicks in the moment the first real customer is typed into the form — and that happens as a matter of routine, without any separate decision by management.

The price of the question has changed. Since 30 May 2025 a new version of article 13.11 of the Code of Administrative Offences has been in force, introduced by Federal Law 420-FZ: a leak of data on between one thousand and ten thousand people costs an organization 3–5 million rubles, more than one hundred thousand people — 10–15 million, biometrics — 15–20 million. A repeat leak carries a turnover-based fine of 1–3% of annual revenue with a floor of 20–25 million and a ceiling of 500 million rubles, while failing to notify Roskomnadzor, Russia's communications and data protection regulator, of an incident costs 1–3 million (overview of the changes, ConsultantPlus). The discount for early payment does not apply to these offences.

The scale of the problem itself is not astronomical, and that is worth knowing so as not to be frightened by headline figures. According to Roskomnadzor data cited by the agency on 22 January 2026, 2025 saw 118 cases of personal data bases being compromised covering 52 million records, against 135 cases and more than 710 million records the year before (ComNews, 22 January 2026). There are fewer leaks, and the fine for ending up in those statistics is markedly larger.

The practical order of work is as follows. Before launch you decide what data the app stores at all and strip out everything unnecessary: often half the fields were added just in case. What remains is moved into a database on a Russian site to which the company has its own access. Backups are set up there too and verified by restoring them: a checkbox in the settings is not yet a backup.

How do roles and access rights appear in the app?

In short: they are designed separately, because a prototype has exactly one role — the author, who is allowed everything.

A generated app assumes by default that anyone who opens it has the right to any action. That follows from how the task was framed: the model was asked to build a request form, and separating access to other people's requests was never mentioned. This is precisely what broke the public stories of 2025 about apps handing strangers other people's data — the breakdown is in the article what vibe coding is.

Access separation is built in four layers, and skipping any one of them devalues the rest:

1. Signing in. Who the user is and how they prove it. A shared password for a whole department means the action log is useless: in it, every action was performed by “an employee”.
2. Roles. A set of actions tied to a job: manager, department head, accountant, administrator. Roles outlive resignations; personal settings do not.
3. Record-level rights. A manager sees their own customers, a head sees the whole department. The check has to sit on the server side: hiding a button in the interface is not enough, the data request goes out without the button too.
4. Action log. Who changed what and when. Without it, settling any dispute turns into interviewing employees.

One thing gets checked separately, because in prototypes it is almost always wide open: the addresses of internal pages and exports. If a report on all deals is reachable by a direct link for anyone who got that link, role separation is already not working.

How do you connect the app to 1C and CRM?

In short: the app does not keep reference data of its own — it pulls it from the systems that own it and returns the result there.

A prototype usually stores counterparties and prices itself — they were typed in by hand during assembly. In real work this turns into divergence: in 1C the counterparty has been renamed, the contract closed, the price changed, while the app lives with an old copy. A quarter later the two systems show different amounts, and trust in both runs out.

Dividing ownership removes most of the arguments:

• 1C owns counterparties, product catalogues, prices and money. Company details, stock balances and limits come from there.
• CRM owns the customer and the deal. The responsible manager and the stage of work come from there.
• The app owns its own process. Requests, site measurements, routes, checklists — the very thing it was built for. What goes back is the result: a document, a status, an amount.

Technically this is an ordinary exchange, and the method is chosen by volume and by the cost of an error — the schemes are covered in the article system integration: methods and stages. For an app that grew out of a prototype, two things are critical that nobody asks about in a chat with a model. The first is behavior when the neighboring system is unavailable: the exchange must resume once the connection is back and keep what has accumulated. The second is protection against repeat processing: if the accounting system's reply never arrived, sending again must not create a second document for the same amount.

If half the accounting has been living in spreadsheets until now, the order of work is the same as described in the breakdown of when a business should move off Excel: first you agree where the truth is stored, and only then build the exchange.

What happens to the app on the next request to the model?

In short: what you asked for gets changed, and sometimes what you did not ask about breaks.

The model sees the text of the program, not a map of dependencies between screens and calculations. In a three-screen prototype there are few connections, and the edit lands cleanly. In a thirty-screen system the same edit touches a neighboring scenario — usually the one opened once a month, at period close.

Industry measurements show that the material for such breakage accumulates. GitClear's study “The Maintainability Gap”, published in June 2026 on 623 million code changes from 2023 to 2026, records eight quality signals. Duplication of code blocks grew by 81%, copying within a single change by 41%, constructs that mask errors by 47%, while moved lines, the marker of refactoring, fell by 70% against the 2022 level. What this means for the owner of an applied system: the same calculation sits in several places, and fixing one of them leaves the rest working the old way.

The second observation is about pace. The DORA report “State of AI-assisted Software Development”, published by Google Cloud on 23 September 2025 from a survey of almost 5,000 specialists, showed that 90% of respondents use AI, delivery speed rose, and the link with delivery stability remained negative. The authors frame the conclusion as amplification: AI amplifies what a team already has and adds no maturity by itself. Where there are no automated tests and no fast feedback, the number of changes grows along with the number of incidents.

Hence the minimum set of safeguards that separates a system from a prototype:

1. Tests for money and accounting scenarios. Calculating an amount, a discount, posting a document, exchange with 1C. Run before deployment, while the change has not yet reached users.
2. A separate environment for checking. A copy of the system on test data, where a change lives before it goes into service.
3. Version history and rollback. The ability to undo the last edit in minutes, instead of reassembling the system from memory.
4. A record of what changed. A short note on “what and why” for every edit: six months later it is worth more than the code itself.

Who fixes the app on Monday morning?

In short: whoever was named in advance; in the absence of such a person, the fixing starts with whoever complains loudest.

A failure in a working system means the process stops. Requests are not accepted, documents do not print, a report shows the wrong amount. Everything after that depends on things prepared before the incident, not during it.

• Access. Hosting, database, domain and mail service are registered to the company. If the keys are in the personal account of the employee who assembled the prototype, the company has a working app and no system.
• Logs and monitoring. Errors are recorded and visible, rather than pieced together from screenshots in a messenger. An availability check reports the app going down before users do.
• Backups. Made on a schedule and verified by restoring them. A copy that has never been deployed remains a hope.
• A named owner. A person inside the company who decides what counts as an incident and sets the queue for fixes.
• Support. An agreement on who fixes the code and within what timeframes. In-house or with a contractor — but settled in advance, before the first incident.

Diagnosing breakage in a generated app is separately expensive. In the Stack Overflow Developer Survey 2025, where 84% of developers use or plan to use AI tools, the main complaint is solutions that are “almost right, but not quite” (66%), and the second most frequent is that debugging generated code takes more time (45%). That is about professionals who read code. For an app assembled by someone who never read the code, the search for a cause starts with reading the whole project from scratch.

At what volume does a prototype have to be rewritten?

In short: at the shape of the load and the cost of the next edit; the user counter says little about it.

The question “how many people will it handle” is the one asked most often, and it is almost always the wrong one. Twenty people reading a reference list live comfortably. Five changing the same stock balance at once break an app that was not built for simultaneous writes. What you have to look at is the signs.

The first three signs are fixed pointwise and require no rewrite. The last three mean it is cheaper to build the system afresh on a validated intent. The moment this becomes obvious is easy to identify: if verifying the next edit costs more than building the same scenario again, extending the app has turned into maintaining the system instead of developing it.

The prototype is not thrown away in the process. It remains the best possible specification: it shows the screens, fields, order of actions and the exceptions that surfaced in practice. Showing “I want it like this” is more precise than describing it in words — and that is the main benefit of the evening spent assembling it.

What does it take for the app to work at your company?

In short: before work begins, the company closes seven questions, and not one of them can be settled on the contractor's side.

1. A described process. Who initiates an action, what statuses a document goes through, what counts as completion. A prototype shows screens but does not show the rules by which they work.
2. A list of data. What the app stores, what it pulls from neighboring systems and what must not be in it at all. This is also where the question of personal data and the storage site is settled.
3. Access to accounting systems. The ability to read from and write to 1C and CRM: a technical user, rights, a test environment for checking the exchange.
4. Roles and access separation. Who sees amounts, who edits reference data, who closes the period. A list of roles is easier to draw up before development than to bolt on afterwards.
5. Rules for a failure. What counts as an incident, who takes the decision, how the department works while the system is unavailable.
6. An owner after launch. An employee who is accountable for the system, collects feedback and sets priorities. Without one, changes arrive as a stream of requests in a messenger.
7. Support. An agreement on maintenance, updates and recovery. A system lives for years, and this is a separate line in the budget; it does not come free with handover.

The first two points require no development budget and deliver a noticeable part of the result on their own. They also explain why the timeline and cost cannot be named over the phone: the price is assembled from the number of scenarios, the depth of the link with accounting and the number of exceptions in the process.

Off-the-shelf, or a system built around your process?

A ready-made product covers a standard process, and on a standard one it is enough: warehouse records, tasks, a customer base. The fork runs through exceptions and data. Internal rules, reference lists, approval thresholds, access rights and calculation rules differ at every company — and they are exactly what determines how the app calculates and who sees what. An off-the-shelf product runs the process by someone else's model, and the gap between that model and yours is closed by employees working by hand; at that moment the saving on the license disappears.

The second reason to look beyond the box is connectivity. The app is useless in isolation from the counterparty, the stock balance and the amount, and those sit in 1C and CRM. Without two-way exchange it becomes one more place where the same data is stored separately and drifts away from accounting. We covered the fork between a ready-made product and a system built around your process separately — your own system or off-the-shelf.

Here, too, is the answer to why a vibe-coded prototype does not turn into a system by itself. It was assembled for one person and their data, while a system has to carry several employees, access rights, exchange with accounting and the handling of failures. The issue here is not the quality of code generation: the prototype was simply never asked for any of the above.

At INCUBE AI we take such apps to working condition as custom development: we move the data into a Russian environment, set up roles and rights, build the exchange with 1C and CRM, add logs, monitoring and tests, and discuss support along with the project. We work under contract, and the data stays in Russia. The site you are reading, and the pipeline that publishes its articles, are built by a human plus an AI agent working together — with the difference that every change goes through tests and review. If you have a prototype that has taken root in a department and a question about what to do with it next — tell us about the task: we will look at what is worth keeping in it, what should be built anew, and what running it will cost.

Sources

• Federal Law “On Personal Data” of 27 July 2006 No. 152-FZ, article 18, part 5, ConsultantPlus — the requirement to carry out the recording, systematization, accumulation, storage, amendment and retrieval of Russian citizens' personal data using databases located on the territory of Russia
• Personal data: new fines from 30 May 2025, ConsultantPlus — the version of article 13.11 of the Code of Administrative Offences under Federal Law 420-FZ: 3–5 million rubles for a leak of data on 1,000–10,000 people, 10–15 million for volumes above 100,000, 15–20 million for biometrics, a turnover-based fine of 1–3% of revenue for a repeat leak, 1–3 million for failing to notify Roskomnadzor
• ComNews, 22 January 2026: Roskomnadzor on the number of personal data leaks in 2025 — 118 cases of databases being compromised and more than 52 million records in 2025, against 135 cases and over 710 million records in 2024
• GitClear. “The Maintainability Gap: 2026 AI Code Quality Research”, June 2026 — 623 million code changes from 2023 to 2026: duplication of blocks grew by 81%, copying within a change by 41%, constructs that mask errors by 47%, moved lines (refactoring) fell by 70% against the 2022 level
• DORA. “State of AI-assisted Software Development”, Google Cloud, 23 September 2025 — a survey of almost 5,000 specialists: 90% of respondents use AI, the link between AI adoption and delivery speed is positive, and with delivery stability negative
• Stack Overflow Developer Survey 2025, AI section — 84% use or plan to use AI tools; the main complaints: solutions that are “almost right, but not quite” (66%) and increased time spent debugging generated code (45%)