If Building Is Free, Why Does Your Vibe-Coded App Cost More Every Month?

Somewhere in your organization there is probably an app that cost nothing to build. A capable engineer described it to an AI model over a few evenings, it worked on the first serious try, and people started using it. Nobody filed a purchase request. Nobody wrote a business case. That is exactly what made it feel free.

Six months later, the same app has a cost. It is spread across an engineer’s week, a cloud invoice, a security review someone squeezed in, and the hours other people spend working around its gaps. None of it appears as a line item, so none of it is ever totaled. The app is not free. It is unaccounted for.

The brake that used to protect you

For most of the history of enterprise software, building something internal was slow and expensive. That expense was annoying, but it did useful work. It forced a conversation before anything got built: is this worth it, who will maintain it, and do we really want to be in the software business for this problem?

The cost was a brake, and brakes are underrated. They make you decide. A company that spent nine months and a meaningful budget on an internal tool knew it had made a commitment, because someone had to sign for it.

Vibe coding took the brake away. When the first version costs a weekend, there is no moment where anyone has to agree to anything. The prototype simply appears, and if it is good, it stays.

AI attacked the easy part of software

In 1986, Fred Brooks argued in his essay “No Silver Bullet” that software difficulty comes in two kinds. Accidental complexity is the effort of expressing an idea in code: syntax, boilerplate, wiring things together. Essential complexity is the difficulty of the problem itself: deciding what the system should do, handling the cases nobody anticipated, and keeping it correct as the world around it changes.

AI coding tools are extraordinary at removing accidental complexity. That is why the first version arrives so fast. But essential complexity is untouched. The questions of what a strategy execution system should do when a team reorganizes mid-quarter, how it should score uncertain work, or who should see which confidential initiative are exactly as hard as they were before. They have just been postponed.

The first version is the cheapest one you will ever ship

Software researcher Meir Lehman observed decades ago that a system in real use must keep changing, or it becomes steadily less useful. Users ask for features. The organization changes shape. Integrations break when other vendors update their APIs. Security patches arrive. Every one of those changes lands on the version that already exists.

This is the part vibe coding does not make cheap. Generating fresh code from a clean prompt is fast. Changing code that real people depend on, without breaking what they rely on, is slow and careful work. It requires understanding what the existing system does, why it does it, and what will happen downstream. That understanding is the expensive part, and it gets more expensive with every month the app is in use.

Unapproved commitments are the most expensive kind

A budgeted project has an owner, a scope, and a review date. An unapproved one has none of these. Its costs are borrowed from wherever they can be found: an engineer’s time pulled from the product roadmap, a manager’s evenings, a cloud account that belongs to another team.

Because the costs are scattered, nobody sees the total, and because nobody sees the total, nobody ever asks whether it is still worth paying. The app continues by default. This is how organizations end up spending more on an internal tool than a specialist platform would cost, while believing the tool is free.

The meter runs where nobody is watching

If you want to know what your vibe-coded app actually costs, look in the places that never appear on an invoice. Count the engineering hours spent on fixes, small features, and access requests. Count the time spent on security questionnaires, data requests, and the occasional incident. Count the hours users spend exporting data to spreadsheets because the app does not do what they need.

Then add the cost that is hardest to see: what those engineers would otherwise have built. Every hour on an internal goal tracker is an hour not spent on the product your customers pay for. Most organizations that run this exercise honestly find the number is larger than they expected, and that it is growing.

Who Carries Each Cost: Vibe-Coded Tool vs Profit.co

Every line in that count lands somewhere. With a vibe-coded tool, it lands on your team. With a platform, it lands on the vendor.

Make the ownership decision on purpose

None of this means the prototype was a mistake. It may have been the fastest way to learn what your organization needs. The mistake is letting it become permanent without ever deciding that it should.

So make the decision explicitly. Ask who will own this app in two years, and whether that person knows it. Ask what it costs per year when every hour is counted. Ask what happens to your strategy process if it stops working on the Monday before a quarterly review. If the answers are comfortable, keep building. If they are not, you have just found the cost that vibe coding hid.

The economics of software have changed less than they appear to. Building got cheap. Owning did not. The organizations that benefit most from AI-assisted development will be the ones that keep that distinction clear, and spend their engineering effort where ownership is worth the price.

The next question is when, exactly, a prototype crosses the line into something you own. Usually, it happens without anyone noticing.