What a vibe-coded application needs before it goes into production

A vibe-coded application that works is a prototype. Moving it into production is a separate project, and almost all of that project is work that was never visible during the build.

‍

The list nobody writes first

• Authentication, authorisation, and proper handling of credentials and secrets
• Data integrity when a process fails halfway or two people edit the same record
• Error handling and monitoring, so failures are noticed by a system rather than by a customer
• An audit trail that can answer who did what, and when
• Backup, recovery, and a tested answer to "what if this is gone tomorrow"
• Integrations that degrade gracefully when the other side changes or goes down
• Compliance requirements, including where data is stored and how long it is kept
• Documentation good enough that a second person can safely change the system

‍

Security is a maintenance problem

A known vulnerability is a security flaw that has already been discovered and documented, and usually already has a fix available. Someone still has to install it.

Verizon's 2026 Data Breach Investigations Report found that exploiting a known vulnerability has become the most common way attackers get in, rising to 31% of breaches from 20% the year before. Only around a quarter of known exploited vulnerabilities were fully remediated, and the median time to fix one stretched to 43 days.

The vulnerabilities being exploited already have fixes available. What is missing is someone whose job it is to apply them. An application nobody owns is an application nobody patches.

‍

Applications get hard to change before they get big

Two terms matter here. Duplicated code is the same logic copied into several places, so one change must be made repeatedly and is easily missed. Refactoring is the housekeeping that prevents this, reorganising what exists without changing what it does.

GitClear's analysis of 623 million code changes between 2023 and 2026 found duplicated code blocks up 81% and refactoring activity down around 70% against pre-AI levels. AI is very good at adding code and much less inclined to reorganise what is already there.

‍

‍

The practical consequence is familiar. The first few features arrive in hours, the tenth takes a week, and nobody can fully explain why.

‍

Three honest ways forward

Harden what exists. Appropriate when the application is small, the logic is sound, and the organisation is willing to hire the capability to own it properly. Scope it as an engineering project with a budget, not as a cleanup.

Rebuild using the prototype as the specification. Appropriate when real use revealed that the process is meaningfully different from what was originally assumed.

Move the process onto a platform that carries the ownership. Appropriate when the value sits in the process rather than in the software being uniquely custom.

There is a fourth option, which is to leave it in production and hope. It is the most common one, and the only one that gets more expensive every month.

The question is not whether the code is good. It is whether the organisation is prepared to own the software. That is the argument behind total cost of ownership, and it is why judgement matters more than code. Choosing between the three routes above is a business decision that happens to concern technology.

‍

How Triggre approaches this

At Triggre, the starting point is the process rather than the code.

When a prototype has revealed how a process actually works, that understanding can be rebuilt as a working application without taking on the long-term burden of custom software. Hosting, security updates, maintenance, and platform improvements are handled by the platform itself, which removes most of what makes production readiness expensive.

The learning from the prototype is kept. The ownership problem is not inherited along with it.