We run your vibe coded app

Something changed in the last year and it is not subtle: a person who has never written code can now describe a working application and get one. Not a mockup. A running thing with a database, a login screen and a form that saves.

That is genuinely new, and it is genuinely useful. The people who understand a business process — the ones who know that the invoice goes to the client before the job sheet, that the roster closes on Thursday, that the discount needs a second approval above a threshold — can now build the software that process needs, without waiting six months for a development queue.

So the first half of the problem is solved. This article is about the second half.

What the demo does not cover

A vibe coded app usually works beautifully in the state it was born in. It is when it meets the world that the list starts.

Authentication and tenancy. One user is easy. Two users who must not see each other's data is a data model decision, not a feature. Most prototypes store everything in one table with no owner column, and retrofitting tenancy after real customer data exists is the most expensive change in software.

Secrets. The fastest way to make a prototype work is to put the API key where the code can see it — which, in a browser app, means the user can see it too. Keys get scraped from public repositories within minutes.

Migrations. A schema change on a table with real rows, at 2pm on a Tuesday, with no rollback, is how a working app becomes an outage.

Backups. Not the existence of a backup job — the restore you have performed and timed. Until then you have a hope, not a recovery plan.

Deployment. "Works on my machine" becomes "works until the next dependency update". A deploy that cannot be rolled back in one command is a deploy nobody dares to run.

Observability. When it breaks — and it will — someone needs logs, an error trace and an alert. Without them, every incident is archaeology.

Cost. Prototypes are cheap because nobody is using them. The first month with real traffic is when the hosting bill, the database tier and the AI token spend all arrive at once.

Compliance. Where the data sits, how long it is kept, who can read it, and what happens when a customer asks for deletion. These are not features you add later; they are properties of the system you built.

Why companies are the right people to build

There is a reason this is happening inside businesses rather than inside software houses. The hard half of building software was never typing the code — it was knowing what the software should do. A company already holds that knowledge: the exceptions, the approval chain, the customer who always pays late, the report the board actually reads.

AI collapsed the other half. That is why a manager can now produce in an afternoon what used to be a quarter of a developer's time.

What AI did not collapse is the distance between "a working app" and "a service". That distance is not intelligence; it is discipline — and it is a different job, done by different people, on a schedule.

The offer, plainly

You vibe code. We host and maintain.

You keep the part only you can do: deciding what the app should do, and changing your mind as you learn. We take the repository and do the part that has no demo: the hardening, the deploy, the monitoring, the backups, the patching, the small changes at 9am on a Monday, and the call when something breaks.

In practice that means a named engineer who knows your system, a staging environment that mirrors production, a restore that has been tested, alerts that reach a human, and a monthly cost you can predict. You keep the business knowledge and the product decisions. We carry the operational risk.

It is a less exciting pitch than "build an app with AI". It is the one that decides whether the app is still running next year.

If you have a prototype that works and nobody to run it, that is exactly the conversation. Write to us with the repository and a sentence about what it does.

Source: ABN Asia's own client engagements, 2026. The effort split above is a rule of thumb from that work, not a measured statistic.

Contact: [email protected]