Would Your Software Project Still Make Sense If AI Prices Doubled?

First, which AI bill are we talking about?

A pricing concern came up in the discussion around our build-versus-buy article. If cheap AI tools make custom software attractive today, what happens if those tools stop being cheap? The answer depends on how the software is built and what it needs after launch.

An engineer might use an AI coding assistant to build an approval system. The finished system could run without sending a single request to a language model. A change in the coding tool’s price would affect future development and maintenance work, but it would not automatically add a new charge to every approval.

Changes to tool limits or availability could also change how long that work takes. If the estimate assumes a particular level of AI assistance, ask what happens when the team has less of it.

A document-processing application that calls a model for every file has a different exposure. Its AI bill depends on how much work it handles, the requests it makes and the provider’s rates. A development subscription and production API usage are different cost models, even when a plan bundles some credits. Check the allowances and what happens when they run out.

So keep three lines separate: the AI tools the team uses, the AI services the application consumes, and the rest of the work needed to keep it useful. Calling all three ‘the AI cost’ makes the decision harder than it needs to be.

A doubled AI bill is not a doubled project cost

Take a fictional internal document tool. Allow $12,000 to build, integrate and introduce it. Once it is running, allow $200 a month for model usage and $800 for hosting, maintenance, support and human review. These are invented round numbers to explain the calculation, not an Essential quote, a client result or typical market pricing.

At the same workload, doubling the model rates takes the monthly AI bill from $200 to $400. Total monthly cost rises from $1,000 to $1,200: an increase of 20%, not 100%. Including the unchanged initial build, the first-year total rises from $24,000 to $26,400, or 10%.

Only model rates change in this comparison. Usage, scope and other costs are held constant to isolate the effect of that one assumption. Real estimates also need to account for growth, taxes, transition costs and the support required by the actual application.

That still doesn’t tell us whether to build it

An extra $2,400 in the first year could be manageable or enough to change the decision. We need to know what the tool improves, how reliably it does that and what the alternatives cost. The same calculation could favour a SaaS product, a small integration or leaving the process alone.

We also need to be honest about benefits. Giving the team five hours back each week can be valuable, but it is not automatically five hours of cash savings. Where will that time go? Will it help clear a backlog, serve more customers or avoid additional hiring? And will people actually use the tool?

Try being wrong about usage as well

Price is only one assumption. Suppose the tool handles three times as much work, while model rates double. With the same request mix, the illustrative $200 AI bill becomes $1,200. Even holding the other $800 fixed, monthly cost reaches $2,000. In practice, review effort and infrastructure may change too.

More usage might also bring more value. Or it might mean repeated attempts, unnecessarily long prompts or people using an expensive feature for tasks that don’t need it. Measure the cost of getting a useful task completed, including review and rework, rather than counting requests alone.

Test the less comfortable cases separately: adoption is slower than expected, integration takes longer, or maintenance needs more attention. Then combine the assumptions that could realistically go wrong together. This is a way to find the weak part of the plan, not a prediction that AI prices will rise.

Leave yourself a practical way to respond

Know who receives a spending alert, who can limit usage and what customers see when a limit is reached. A bill warning without an owner is easy to miss. A hard stop without a recovery path can turn a cost control into an operational problem.

Some tasks may work with a smaller model, a shorter input or a conventional rule. Test that against the quality the workflow needs. Switching providers also takes work: privacy requirements, behaviour, integrations and evaluation all need checking. It is an option to assess, not a free escape hatch.

And name the maintenance owner. AI can help with updates and diagnosis, but someone still has to decide what to change, verify it and respond when an integration breaks. Include that responsibility in the budget from the start.

Ask for the assumptions, not just the development price

Before approving a project, ask for a baseline and a few downside cases over the same period. Compare building, buying and extending an existing system against the same outcome. Include implementation, migration, training, subscriptions, operations and support, without counting the same allowance twice.

If the project only works financially while a promotional credit lasts, that matters. If it remains useful with higher costs and slower adoption, there is a stronger reason to proceed. Sometimes the best result of this exercise is a smaller scope.

A project doesn’t need to survive every imaginable price increase. But it should survive a few assumptions being wrong. Essential can help put those assumptions on the table before you commit to the build.