Written by Technical Team | Last updated 23.07.2026 | 18 minute read
Custom AI development in the UK can cost anything from around £10,000 for a tightly defined discovery or feasibility exercise to well over £500,000 for a production platform that connects to several business systems, processes sensitive data and supports large numbers of users. A focused proof of concept commonly sits between £25,000 and £75,000, while a production-ready minimum viable product is more likely to require £75,000 to £200,000. Complex, regulated or business-critical programmes can move into the £200,000 to £600,000 range, with enterprise-wide platforms exceeding £1 million when they involve multiple workstreams, extensive data engineering, high availability and formal assurance.
Those figures are deliberately broad because “custom AI” describes very different types of system. A private knowledge assistant that searches approved company documents is not comparable with a computer vision platform inspecting thousands of images per hour. An email-triage tool that recommends a category to a human operator is not comparable with an autonomous agent that updates customer records, issues refunds and triggers downstream workflows. Both may use artificial intelligence, but their engineering effort, operational risk and cost structure are fundamentally different.
The most useful way to estimate custom AI development cost is therefore not to ask how much the model costs. It is to examine the complete system required to turn a model into a reliable business capability. The model may be one component among APIs, data pipelines, identity controls, databases, user interfaces, monitoring services, human-review queues and integrations with existing software. In many projects, the AI API bill is a relatively small operating expense; the larger investment is the engineering required to make the application accurate, secure, maintainable and useful.
For budgeting purposes, most UK custom AI projects fall into five practical bands. These are indicative commercial ranges rather than fixed prices, and they normally exclude VAT, third-party licence fees and unusually large data-acquisition costs.
The same apparent feature can sit in several bands. A chatbot that answers questions from twenty public webpages may be a small project. A “chatbot” that authenticates staff, retrieves permissions-aware content from SharePoint and a data warehouse, reasons across several sources, creates cases in a CRM, redacts personal data, records evidence for every answer and meets a strict service-level objective is an enterprise application. The user interface may look equally simple, but the second system contains considerably more engineering below the surface. Location also affects UK pricing, although less predictably than it once did. London-based specialists and scarce AI roles can command higher rates, but remote delivery has narrowed some regional differences. The greater determinant is usually the seniority and composition of the team. Experienced AI architects, machine learning engineers, MLOps specialists, security engineers and technical leads cost more than generalist developers because they are responsible for decisions that affect reliability, scalability and risk. Commercial contractor rates for relevant UK roles often begin around £500 per day and can exceed £1,000 per day for scarce senior expertise. A consultancy’s blended rate may be higher than an individual contractor’s rate because it also covers delivery management, quality assurance, design, internal review, business continuity and organisational overhead. A realistic estimate should also distinguish capital build cost from ongoing operating cost. Once live, an AI system incurs model or compute charges, cloud hosting, databases, storage, monitoring, security tooling, support, incident response and continuous evaluation. A modest internal application may operate for hundreds or a few thousand pounds per month. High-volume conversational systems, real-time vision, voice processing, agentic workflows or dedicated GPU deployments can create five-figure monthly bills. Annual maintenance and optimisation may reasonably require 15% to 30% of the original build cost, particularly where models, prompts, integrations and business processes change frequently.
The first cost component is discovery, which is often misunderstood as a series of stakeholder meetings. Good AI discovery is an engineering activity. The team needs to define the decision or workflow being improved, establish measurable acceptance criteria and identify how the system will fail. It may test whether sufficient data exists, whether the available labels are trustworthy, whether a foundation model can handle domain language, whether latency is acceptable and whether the intended automation is legally and operationally appropriate. This phase can prevent a business from spending six figures on a technically impressive system that cannot be validated or adopted. Discovery is usually between 8% and 15% of a well-structured project, although uncertain or research-heavy work may require more.
Data engineering is frequently the largest hidden cost. AI demonstrations are often built with a carefully selected spreadsheet or a folder of clean documents. Production systems must deal with duplicated records, missing fields, inconsistent identifiers, scanned files, outdated content, access restrictions, changing schemas and data that sits across several platforms. Engineers may need to create extraction pipelines, clean and normalise information, map entities, design retention rules, generate training labels, implement document chunking, build embedding indexes or synchronise data from operational systems. For predictive machine learning, they may also need to prevent data leakage, construct time-aware training sets and reproduce features consistently between training and inference. Data work commonly consumes 15% to 35% of the budget, and it can exceed that where the organisation’s information estate is fragmented.
The AI engineering component covers model selection, prompt and context design, retrieval, fine-tuning, classical machine learning, computer vision, forecasting or optimisation logic. Using an existing model through an API is usually faster and cheaper than training a model from scratch, but it does not remove the need for engineering. The team must compare candidate models, define fallback behaviour, control context length, handle structured outputs, test tool calls and determine when a smaller model can perform the task more economically. For retrieval-augmented generation, model work includes more than installing a vector database: the system needs ingestion rules, chunking strategies, metadata filters, ranking, citation or evidence handling, freshness controls and evaluation against representative questions. AI engineering may account for 15% to 30% of a project, depending on whether the system relies on configurable foundation models or bespoke trained models.
Software engineering and integration usually consume another substantial share. The AI capability needs a secure application around it: APIs, interfaces, workflow states, user permissions, queues, error handling, business rules and connections to systems such as Microsoft 365, Dynamics, Salesforce, SAP, finance software, data platforms or custom databases. Legacy integrations are particularly difficult to estimate because documentation may be incomplete and test environments may not match production. An apparently simple requirement such as “update the CRM” can involve identity federation, field mapping, duplicate detection, rate limits, retries, approval rules, audit logs and reconciliation after partial failure. Integration and application development often represent 20% to 40% of the budget because this is where probabilistic AI meets deterministic business processes.
Productionisation adds cloud architecture, security, DevOps and MLOps. Engineers need separate environments, infrastructure as code, secret management, network controls, CI/CD pipelines, model and prompt versioning, rollback mechanisms, telemetry, alerting and capacity planning. AI-specific monitoring may track latency, token consumption, retrieval quality, answer groundedness, tool-call success, refusal behaviour and changes in input patterns. Security testing must consider conventional application threats as well as prompt injection, sensitive-information disclosure, unsafe output handling, excessive permissions and manipulated documents. In regulated or high-impact environments, the project may also require a data protection impact assessment, threat modelling, explainability, accessibility work, clinical or domain assurance, penetration testing and documented human oversight. These activities are not optional polish; they are what separate a demonstration from a service that can be responsibly operated.
Evaluation deserves its own budget because AI quality cannot be established through ordinary unit testing alone. Deterministic code can be checked against an exact expected output, whereas an AI system may produce several acceptable answers and occasionally fail in unexpected ways. A production project needs a representative evaluation dataset containing normal cases, edge cases, adversarial inputs and examples from different user groups. The team must define metrics, establish thresholds and decide which failures require blocking, warning or human review. Human experts may need to score outputs where automated metrics cannot capture correctness or harm. Evaluation work often expands as the project matures: a prototype may be checked manually, but a live service needs repeatable regression tests every time a model, prompt, retrieval source or workflow changes.
The most important architecture decision is whether to buy, configure, integrate or build. A business may only need a licensed software product with modest configuration, in which case a custom build would be unnecessary. At the other extreme, a genuinely differentiated product may require proprietary workflows, specialist data pipelines and custom interfaces. Between those points sit many hybrid approaches: an existing foundation model combined with custom retrieval; a commercial document-processing service with bespoke validation; an open-source model deployed inside a private environment; or an AI agent that uses established business APIs. The cheapest credible architecture is normally the one that reuses commodity capabilities while reserving bespoke engineering for the parts that create business value.
Model strategy has a direct effect on both build and operating costs. API-hosted models minimise infrastructure work and allow a team to switch between model sizes, but they create usage-based charges and dependencies on provider availability, regional options and rate limits. Self-hosting an open model can offer greater control, predictable capacity and specific data-handling benefits, but it introduces GPU provisioning, model serving, optimisation, patching, scaling and specialist operational skills. Fine-tuning can improve consistency for narrowly defined tasks, yet it adds dataset preparation, training runs, evaluation and version management. Training a large foundation model from scratch is outside the scope of most custom software budgets; for the majority of UK organisations, the commercially rational choice is to adapt existing models rather than attempt to create a new general-purpose model.
The level of autonomy is another major multiplier. A system that drafts a response for a person to approve is cheaper and safer to implement than one that sends the response automatically. A recommendation tool can tolerate different failure modes from an agent authorised to modify financial records. As autonomy increases, the system needs stricter permissions, transaction limits, approval gates, idempotency, rollback, monitoring and evidence trails. It may require a policy engine that determines which actions are allowed, a sandbox for executing tools and a human-review queue for uncertain cases. Each additional action also creates integration and test scenarios. For this reason, the cost of an agent should be estimated by the number and risk of the actions it can take, not by the number of conversational screens it has.
Several technical choices repeatedly increase project cost:
A useful insight is that model accuracy is not the same as system value. A more expensive model may be cheaper overall if it reduces manual review, completes tasks in fewer steps or produces structured outputs reliably. Conversely, using the most capable model for every request can waste money when classification, extraction or routing could be handled by a smaller model or deterministic code. Cost optimisation should therefore happen at workflow level. The relevant measure is the cost per correct, completed business outcome, including retries and human intervention, rather than the headline price per token.
Architecture also affects how quickly the system can change. Hard-wiring a project to one model, one prompt or one provider may reduce initial development time, but it can make later migration expensive. A well-designed AI layer separates model access, business rules, evaluation and user experience. This creates some upfront engineering cost, yet it allows the organisation to compare models, introduce fallbacks and respond to provider or pricing changes. The right balance depends on the expected lifetime of the product. A three-month experiment should not be over-engineered as a platform, but a business-critical service should not be built as a disposable prototype.
Consider a focused internal knowledge assistant for a 100-person organisation. The system needs to answer questions from approved policies and project documents, use existing staff authentication and show the source material behind each answer. If the documents are accessible, reasonably clean and stored in one platform, a proof of concept may cost £25,000 to £50,000. A production version with permissions-aware retrieval, automated content synchronisation, a managed interface, evaluation, analytics and support is more likely to cost £60,000 to £120,000. The lower figure assumes limited integrations and moderate usage; the upper figure reflects more complex access controls, document formats and assurance. Ongoing cloud and model costs might remain modest, but content governance and evaluation will still require ownership.
Now consider intelligent document processing for invoices, claims or application forms. The system may need to ingest email attachments and scans, classify documents, extract fields, validate values against a finance or case-management system and route exceptions to a person. A pilot using a few document types can fall between £40,000 and £90,000. A resilient production workflow may cost £100,000 to £250,000 because accuracy must be measured field by field, poor-quality scans need handling, business rules need to be encoded and every transaction needs an audit trail. If handwriting, complex tables, multiple languages or high financial risk are involved, both data-labelling and human-review costs rise.
A customer-service copilot that summarises conversations, retrieves account information and drafts suggested replies commonly costs £75,000 to £180,000. It can be cheaper when it only works inside one channel and never takes action. It becomes more expensive when it spans email, chat and telephony; retrieves data from several platforms; applies customer-specific policy; identifies vulnerability or safeguarding concerns; and writes back to the CRM. Voice adds streaming transcription, speaker handling, latency constraints and additional evaluation. Automatic outbound responses add approval logic, tone controls, complaint handling and more extensive risk testing. The operational cost must include not only model usage but also contact-cententre integration, observability and continuous review of failed interactions.
A predictive maintenance or forecasting solution has a different cost profile. A feasibility study may cost £20,000 to £50,000 if historical data is already available. A production system can range from £100,000 to £300,000 or more because the difficult work lies in joining operational data, defining the prediction target and integrating outputs into planning or maintenance workflows. Sensor data may need streaming ingestion and quality monitoring. Historical records may be biased by previous maintenance decisions. The system needs back-testing across time rather than random train-test splits, and predictions need to be calibrated so operators can understand confidence. If the output affects safety-critical equipment, domain validation and conservative deployment substantially increase the budget.
A computer vision inspection platform can begin with a £40,000 to £100,000 proof of concept, provided representative images and expert labels exist. Production deployment may cost £150,000 to £500,000. Cameras, lighting, edge devices and physical installation can matter as much as the model. The team must define what constitutes a defect, label enough examples, test variations in angle and environment, and determine how false positives and false negatives affect operations. Real-time processing may require optimised models at the edge, while central monitoring needs secure device management and version control. A model that performs well on a curated image set may deteriorate when camera positions, products or environmental conditions change, so ongoing data collection and retraining must be planned from the outset.
An agentic operations platform that reads incoming requests, gathers information from multiple systems, decides the next step and executes approved actions is usually a £200,000 to £600,000 programme rather than a simple chatbot project. The cost comes from orchestration, permissions, state management and exception handling. The agent needs to know which tools it may call, which data each user may access and when a human must approve an action. It must cope with timeouts, partial failures, duplicate requests and contradictory information. Every automated action needs traceability. A multi-agent design can add value where specialist components genuinely require separate context or permissions, but it also increases latency, token usage and test complexity. One well-structured workflow is often cheaper and more reliable than a collection of loosely controlled agents.
For a representative £150,000 production AI MVP, the budget might be allocated approximately as follows: £15,000 for discovery and architecture; £25,000 for data engineering; £25,000 for model, retrieval or machine learning work; £35,000 for application development and integrations; £20,000 for cloud, DevOps and MLOps; £15,000 for evaluation, security and assurance; and £15,000 for delivery management, quality assurance, documentation and handover. This is not a universal formula. A data-heavy forecasting project may shift money from interface development into data engineering, while an AI-enabled customer portal may require more product design, accessibility and front-end work. The example is useful because it demonstrates why the visible “AI feature” may represent less than a quarter of the total budget.
Timelines should be interpreted with equal care. A six-week proof of concept can test technical feasibility, but it is unlikely to include all production controls. A credible MVP commonly takes three to six months. A complex programme may take six to eighteen months, particularly when access to data, procurement, security review or stakeholder decisions create dependencies. Adding more developers does not reduce every timeline because model evaluation, domain review and integration testing contain sequential work. Unrealistically compressed schedules usually reappear as higher risk, rework or technical debt.
The most effective cost control is to narrow the first production scope around one measurable outcome. Instead of commissioning a general AI platform, define a workflow such as reducing the average handling time for a specific request type, extracting five fields from one document family or improving forecast error for one operational decision. A narrow scope reduces data variation, integration work and evaluation complexity. It also produces evidence that can justify expansion. The aim is not to build a disposable demo, but to establish a small production slice with architecture that can evolve.
Businesses should separate uncertainty that requires experimentation from engineering that is already understood. A short discovery or technical spike can answer whether a model can achieve the required accuracy, whether documents are retrievable with the necessary permissions or whether latency is acceptable. Once those questions are answered, the production build can be estimated with greater confidence. Fixed-price delivery is most credible when requirements, data access and acceptance criteria are clear. Where they are not, a staged commercial model prevents suppliers from pricing every unknown as risk or, worse, underpricing the work and recovering margin through change requests.
Cost can also be reduced through model routing, caching and selective automation. Deterministic rules should handle deterministic tasks. Smaller models can classify, extract or route straightforward requests, while stronger models are reserved for complex reasoning. Repeated context can be cached, long documents can be retrieved selectively and non-urgent workloads can be processed in batches. Human review should be targeted according to confidence and consequence rather than applied to every case forever. These techniques lower both compute costs and operational workload, but they need to be designed and measured rather than added as an afterthought.
Finally, compare suppliers on the completeness of their estimate, not simply the headline price. A low quote may omit data preparation, security testing, production monitoring, documentation, cloud configuration, model evaluation or post-launch support. Ask what environments are included, who owns the infrastructure, how acceptance will be measured, what happens when the model fails, how changes will be deployed and which third-party charges remain outside the price. A credible AI development company should be able to explain the architecture, assumptions, dependencies and risk allowances behind its figure.
The central budgeting lesson is simple: custom AI development cost in the UK is determined less by the novelty of the model than by the difficulty of embedding intelligence into a real organisation. The cheapest system to demonstrate is not always the cheapest system to operate, and the most expensive model is not necessarily the most expensive workflow. A strong business case measures the total cost per reliable outcome, accounts for human oversight and includes the engineering required after launch. With a disciplined discovery phase, a focused initial scope and production standards applied from the beginning, organisations can invest in custom AI without either over-engineering the first release or underestimating what dependable delivery requires.
Is your team looking for help with AI development? Click the button below.
Get in touch