Start here
Lead with the problem, not the technology
Most firms approaching their first real AI implementation make the same mistake: they lead with the technology. They ask “which tool should we buy?” before they have answered “what problem are we actually solving?” The result is a pilot that impresses in a demo and dies on a real client brief.
The fix is to think about infrastructure and budget in the order that produces something your team can actually run — starting with the shape of the stack, not the shortlist of vendors.
The shape
Your stack has two layers, and most firms see one
AI infrastructure has a foundation layer and an application layer. Firms tend to obsess over the second and neglect the first, where most of the trouble actually lives.
- The foundation layer. Where your data lives, how it moves, and who can touch it — storage, pipelines, processing. Ten copies of the same data in different systems is a mess no AI tool will save you from; the first job is one source of truth. On compute, the practical question is whether you need dedicated GPU resource for heavy model work, or whether hosted AI services on standard cloud infrastructure will do. For most firms the latter is sufficient and far cheaper to start with.
- The application layer. Where AI does visible work — the frameworks and tools your team uses to build and run workflows. On open source versus proprietary, the right answer is almost always: pick what your team can actually maintain. Clever solutions only one person understands are a delivery risk, not an asset.
Where firms consistently underestimate is integration. If your implementation does not connect cleanly to your CRM, document store, and project management tool, your team will route around it — and a system people route around is a failed implementation, regardless of what it cost.
The five questions
How to choose tools without backing the wrong one
Vendor noise is the villain. The market is full of platforms that look capable in a sales demo and fall apart on a real brief. The defence is to write the job description for the tool before you evaluate any tools. Work through five questions on every platform:
- What are the actual business requirements? “Automate proposal assembly for our mid-market clients” is a job description. “Use AI for business development” is not.
- Can it scale? If it handles your current load, can it handle three times that without a full rebuild? Growth is not a reason to replace working infrastructure.
- Does it match the skills you have? If your team cannot run it, either budget for training or choose something simpler. Both are legitimate answers.
- Does it integrate? Check against your CRM, ERP, data warehouse, and identity management. No integration means no adoption.
- What is the real cost? Licence fees are only part of it. Add API usage, support, change management, and ongoing maintenance. Prefer open standards, exportable data, and a clear exit path.
On security, ISO 27001, SOC 2, and a Data Processing Agreement are non-negotiable requirements, not nice-to-haves. If you hold client data, regional hosting options matter too.
A system people route around is a failed implementation, regardless of what it cost to build.
The hidden bill
Budget for the costs everyone forgets
Direct costs are straightforward to estimate: cloud or on-premise infrastructure, software licences, API and token spend, data storage, and any initial training or fine-tuning. The indirect costs are where implementations come unstuck.
- Team training and change management. What does it cost to bring your end users with you?
- Ongoing maintenance and monitoring. Models drift, integrations break, usage patterns change.
- Technical debt. Shortcuts in your existing estate become blockers once you try to automate on top of them.
- Governance and compliance workload. Someone has to own the policy, the approved tool list, and the risk register.
- Opportunity cost. Senior time tied up in the implementation itself, not on client work.
Build a 12-month view — not because the numbers will be precise, but because building the view forces you to find the costs you had not thought of. Then work in phases: a proof of concept or structured pilot first, measure the impact, scale what works, retire what does not. That is not caution for its own sake; it is how you avoid committing serious resource to something that has not yet proved its value in your environment.
Protect the budget
Cost optimisation that does not slow delivery
A few practical moves keep spend under control without adding drag. Use serverless compute where you can, so you pay only when code runs rather than for idle resource. Prefer open source where the proprietary alternative offers no meaningful advantage. Turn on usage monitoring and cost alerts from day one, not after the first invoice surprises you. For non-critical model training, spot and preemptable compute cuts costs significantly. Optimise prompt length, context windows, and model size, because token costs compound quickly at scale.
Add a monthly cost checkpoint with your finance team. Five minutes, one chart — that is all it takes to stay ahead of budget drift.
Prove it
How to calculate ROI a board will accept
The ROI conversation needs to happen before the implementation, not after. Set your baseline metrics now — time saved per fee earner per week, error rates in deliverables, revenue per head, client satisfaction scores. Those are your before numbers. Then define what good looks like at 90 days, 6 months, and 12 months.
Track both the tangible and the intangible. Tangible: hours recovered, errors avoided, proposals turned around faster. Intangible: competitive positioning, team morale, capacity to take on more work without adding headcount. Include the full total cost of ownership in the calculation, not just the licence fee. If the picture is not clear after a pilot, run it longer or reduce the scope — do not scale a result you cannot measure.
The road map
Two phases, and the order matters
A sustainable road map has a foundation phase and an expansion phase, run in that sequence.
- Phase one — Foundation. Define your priority use cases, stand up the infrastructure with basic integration, and run your skills uplift. The KWA framework — Knowledge, Workflow, Agents — is useful here: start at the Knowledge layer, establishing a centralised, searchable knowledge base before you attempt workflow automation or agentic work. Trying to build agents on fragmented, inaccessible data is one of the most common and expensive mistakes firms make.
- Phase two — Expansion. Scale the pilots that worked, and only those. Integrate with core systems, add new use cases with the same discipline, and publish ROI updates to build internal confidence.
Each phase should produce something small, shippable, and demonstrable. Wins people can see are what sustain internal sponsorship.
The pitfalls
What goes wrong, and why it repeats
The failure modes are consistent across firms, and each is avoidable with a decision made early.
- No clear objective at the start. If you do not know what good looks like, the project can never be good enough. Define it before you spend anything.
- Unreliable data. AI does not improve bad data — it processes it faster and surfaces problems at scale. Clean your data house before you build on it.
- Skipping governance. Projects that skip it either stall mid-implementation or create a compliance problem after go-live. Govern is the fifth step in the 5 Steps for AI Leadership framework, but the policy, approved tool list, and data handling rules need to be in place before your team touches client work with AI.
- Technology too complex for the team. Start simple, start slow, grow from there. The goal is a system the team can run, not a showcase of technical ambition.
- Treating implementation as a one-off. Open-source models get deprecated, providers sunset old versions, teams upskill, clients raise concerns, and bugs surface in production. You need a plan for each, not just for go-live.
The evidence
A manufacturing example, and the discipline behind it
A mid-size manufacturer with limited technical resource and a £50,000 starting budget began with predictive maintenance on cloud services, tracking ROI monthly from phase one. Over nine months they moved through three stages: foundation work — discovery, infrastructure, data collection, team training — in the first 12 weeks; development and integration through to week 32; then continuous deployment, monitoring, and expansion.
The result was a 30% reduction in downtime and roughly £120,000 in annual savings — a 2.4x return in year one. The lesson is not the number. The lesson is the discipline: focus, prove value in one place, then scale.
AI does not improve bad data. It processes it faster and surfaces the problems at scale.
What to do next
Design the stack, plan the budget, then repeat
The plan has two parts. First, technology stack design: map your business needs against your data infrastructure, list the tools you are considering, identify your integration points, and assess what your team can actually support. Second, budget planning: estimate direct and indirect costs — both of them — build a phased budget, and define what ROI looks like and when you expect to see it.
Neither is a solo task. You need the people who own your data, systems, finances, and delivery in the room to tell you what is actually in the estate and what the team can absorb. Done once, it becomes the foundation for rolling AI out across the business rather than starting over each time.
The controlling idea is straightforward: start small, think big. Balance build versus buy, factor in the full cost of ownership including skills and integration, measure continuously, and pivot based on evidence rather than preference.