Buying AI Because Competitors Are: The Cost of Spending Without a Business Case

The tolerated pain

A competitor announces an AI assistant on its website. A supplier mentions that "everyone" is rolling out AI licences. A board member asks what the business is doing about AI. Within weeks there is a budget line, a pilot or a licence order, and the question being answered is "how do we get AI?" rather than "which problem are we solving?"

The pressure is understandable. Nobody wants to be the business that ignored a shift in technology. But buying a capability before naming the problem turns AI into a cost centre with no measure of success. Six months later the business has invoices, a few enthusiastic users and no way to say whether the money was well spent.

Two related articles look at what happens afterwards. AI subscription sprawl and unmeasured value covers licences that multiply team by team, and the cost of running AI on poor-quality data covers projects that fail because the data is not fit for purpose. This article is about the decision at the start: committing money to AI without a defined business problem and a way to measure the result.

Why businesses buy first and ask later

• Fear of falling behind. Competitor announcements create urgency that feels strategic but is really reactive.
• Vendor framing. Sales conversations start with features and demos, not with your process or your numbers.
• AI feels different. Leaders who would never buy an ERP without a business case treat AI as an experiment that does not need one.
• The problem is hard to name. "Be more productive" is easier to say than "reduce quote turnaround from three days to one".
• Nobody owns the outcome. IT owns the licence, but no business manager owns the result.

Operational symptoms

• an AI budget approved without a list of specific use cases;
• pilots described by the tool used rather than the process changed;
• success reported as "people like it" or number of logins;
• no baseline of how long the target work took before AI arrived;
• several teams trying different tools for overlapping purposes;
• a pilot that never ends and never scales.

What established guidance recommends

Microsoft's Cloud Adoption Framework guidance on setting an AI strategy is candid about the risk. It notes that teams often experiment a great deal and see little return, and that some build conflicting solutions across the organisation. Its first recommendation is to start with business problems before considering AI at all, looking for signals such as repeated manual effort or slow approvals, and to stay focused on outcome gaps that are measurable and meaningful. It then suggests turning each problem into a short statement naming the activity and the expected result, and confirming the activity happens often enough to justify the investment.

The companion guidance on planning for AI adoption recommends ranking use cases on business impact, technical complexity, resource requirements and alignment with goals, then defining specific success metrics, timelines and resources for each. It describes proofs of concept as a way to validate technical feasibility and business value before full-scale development, and suggests starting with internal, non-customer-facing projects to limit risk.

Risk deserves a place in the business case too. The US National Institute of Standards and Technology publishes a voluntary AI Risk Management Framework to help organisations manage the risks AI systems create for people, organisations and society. Even a small business can borrow its discipline: know what the system is for, what could go wrong and who is accountable.

How the pain becomes money

• Technology waste: licences, platforms and consulting paid for without a measurable return.
• Opportunity cost: budget and management attention diverted from problems with a clear payback.
• Labour cost: staff time spent on pilots, training and workarounds that do not change the process.
• Risk exposure: data shared with tools that were never assessed for the use they are being put to.
• Credibility cost: a failed AI project makes it harder to fund a sound one later.

An illustrative comparison

This comparison is illustrative; every figure is an assumption. Picture a Pretoria professional services firm with 60 staff.

The reactive purchase may still help people, but nobody can prove it. The problem-first purchase has a number it must beat, a way to check it and a clear decision point: if query times have not fallen after three months, stop or change course. The point is not that one is cheaper; it is that only one can be judged.

Trade-offs to respect

Insisting on a full business case for every small experiment can be its own waste. A sensible balance is to allow a small, capped exploration budget for learning, while requiring a written problem statement and success measure before any spend that is recurring, organisation-wide or touches client data. Learning is legitimate; open-ended spending is not.

When it becomes commercially urgent

1. An AI budget is about to be approved or renewed without named use cases.
2. A pilot has run for months with no agreed success measure.
3. Staff are pasting business or client data into AI tools nobody has assessed.
4. Different departments are buying overlapping AI products.

What better looks like

Every AI investment starts with a written problem statement owned by a business manager: the activity, how often it happens, what it costs today and what result would justify the spend. A baseline is measured before anything is bought. A small, time-boxed proof of concept tests the assumption. The decision to scale, change or stop is made against the agreed measure. Data and risk questions are answered before rollout, not after. The broader method for weighing systems investments is covered in how to build a business case for systems improvement, and choosing a sensible first process is discussed in how to choose a business process for an AI agent.

Practical next actions

1. List current AI spend and pilots, with the problem each was meant to solve.
2. Write a one-paragraph problem statement for every proposed use case, owned by a named manager.
3. Measure the baseline: volume, time, error rate or cost of the work today.
4. Set a success measure and a review date before buying.
5. Run a short proof of concept on an internal process first.
6. Stop or redirect anything that cannot name its problem.

Mellorca's digital systems architecture and roadmap work helps businesses decide where AI fits among their other systems priorities.

Bottom line

AI can be a sound investment, but only when it is bought to solve a named problem with a measurable outcome. Buying because competitors are buying leaves the business paying for a capability it cannot evaluate. Start with the problem, measure the baseline and give every AI decision a number to beat.

Sources and further reading

• AI strategy - Guidance to set your organization's AI strategy - Cloud Adoption Framework (last verified 10 October 2026)
• Plan for AI adoption - Cloud Adoption Framework (last verified 10 October 2026)
• AI Risk Management Framework (last verified 10 October 2026)

Related Mellorca reading

• Staff Using AI with Company Data Nobody Governs
• The Cost of Business Systems That Do Not Talk to Each Other
• Software Bought Without Approval: The Financial and Security Cost of Shadow IT