The headline story about AI and software is a cost story: building got dramatically cheaper. A system that once needed a team for months can now be produced by one experienced engineer in weeks, or by a founder over a weekend.
That story is true, but it is half of the picture. Building is a one-off cost. Running software is a cost you pay every month for as long as it exists, and AI changed that side of the ledger too — in some places making it larger, not smaller.
This article looks at where the long-term costs of AI-built systems actually sit, and what you can do at design time and afterwards to keep them under control.
Building got cheap. Owning did not.
Every piece of software in production needs a steady stream of work that has nothing to do with new features:
- operating system, browser and platform changes;
- third-party APIs that change or are retired;
- dependencies with newly discovered security holes;
- bugs that only appear at real volumes;
- infrastructure that needs patching, scaling and backing up.
None of this got cheaper because the first version was written faster. If anything, a faster build means more software exists, each piece needing the same care.
Four costs that are new or larger with AI
1. Models change under you
If your system calls an AI model, its behaviour depends on a component you do not control. Providers release new versions, retire old ones and adjust behaviour on their own schedules. A prompt that worked well on one model version can produce subtly different results on the next.
Each change needs testing before you switch. Without an evaluation set — a collection of real cases with known good answers — that testing is guesswork, and problems surface through customer complaints instead.
2. Usage-based bills
Traditional software has mostly fixed hosting costs. AI features are billed per use, so costs grow with success, and a single design decision — sending a whole document to the largest model when a small model and one page would do — can multiply the bill.
The cost is controllable, but only if someone is watching it: cost per task, tracked over time, with the cheapest model that passes your evaluations used for each job.
3. Code nobody fully read
AI-generated code tends to arrive in larger volumes, with more dependencies and more repetition than code written by hand. When nobody on the team fully read it as it was written, the cost appears later, as slower and riskier changes. Every modification starts with working out what the existing code actually does.
This is why our own workflow requires a senior engineer to review every change before it merges; we describe it in how we build with AI. Reading code once, when it is written, is much cheaper than reverse-engineering it during an incident.
4. Security debt
Fast builds skip things: server-side permission checks, secrets management, rate limits, dependency updates. Each one is cheap to do at the time and expensive to discover later — especially if it is discovered by someone else. We walk through the most common gaps in why vibe-coded apps break in production.
Where the budget goes now
A useful way to think about lifetime cost is to split it into three parts:
- Deciding what to build — specification, data and integration work.
- Building it — writing and testing the code.
- Running it — maintenance, security, model changes, usage costs, support.
AI compressed the second part dramatically. It did much less for the first and third. As a result, the share of lifetime cost in specification and running has grown, and a budget that only plans for the build is now planning for the smallest of the three.
Design decisions that lower running costs
Most running costs are decided at design time. A few choices make a large difference:
- Evaluation sets from day one. They make every future model or prompt change a test rather than a gamble.
- Right-sized models. Start with the smallest model that passes your evaluations, and move up only where it fails.
- Limits everywhere. Rate limits, usage caps and billing alerts with every provider that charges by use.
- Monitoring before launch, not after the first incident.
- Tests around the critical paths, so changes can be made safely by people — or agents — who did not write the original code.
- Boring, well-supported technology for everything that does not need to be novel.
Questions to ask before you build
Before approving any new system, especially an AI one, ask:
- Who will own this after launch, and how much of their time will it need?
- What will it cost per month to run at today’s volume? At ten times today’s?
- What happens when the AI model it depends on is retired?
- How will we know if it starts giving worse answers?
- Who reviews its security, and how often?
If nobody can answer these, the build estimate is not the real cost of the project. A discovery phase is where these answers should be produced, before anything is built.
Someone has to own it
The uncomfortable conclusion is that cheap building does not remove the need for ownership; it increases it. More systems get built, each one depending on models, dependencies and APIs that keep changing, and each one needing someone who understands it well enough to keep it safe.
That ownership can sit in your own team, or with a partner on a maintenance and support retainer. What does not work is assuming that because something was cheap to build, it will be cheap to keep.
