What a custom OpenAI integration actually costs a UK business

Build, running and maintenance are three different costs. What moves each one, what makes a project cheap or expensive, and how to sanity-check a quote.

John Kelleher
John Kelleher

Someone has asked what it would cost to build AI into one of your processes, and you have to put a number in front of a board. Perhaps two suppliers have quoted, the numbers are a long way apart, and neither document explains why.

No supplier can price this from a brief. What can be answered is the structure: what the money buys, which decisions move the number, and which questions expose a figure arrived at without anyone looking at your systems.

Start where most quotes go wrong. "What does it cost" is three separate questions: the cost to build it, the cost to run it, and the cost to keep it working. Most proposals price the first, some estimate the second, and almost none price the third, which arrives later as an unbudgeted emergency.

The cheapest integration is often the one you do not commission

Before any of that, check whether you need to buy engineering at all, because much of what used to require a build is now covered by a subscription you may already hold.

OpenAI introduced workspace agents on 22 Apr 2026, describing them as "an evolution of GPTs", for ChatGPT Business, Enterprise, Edu and Teachers. OpenAI still describes them as a research preview, and on Enterprise and Edu they are off until an admin enables them. Without an engineer they run on a schedule, can be triggered automatically, keep working in the cloud while the person who set them up is offline, operate in Slack as well as ChatGPT, connect to external apps, carry version history and approval steps on write actions, let you choose per connected app whether the agent runs on each user's own login or on a shared agent-owned account, for which OpenAI recommends a service account, and can be shared and transferred across a team. Pricing moved to a credit-based model on 06 May 2026.

That covers a lot of what people commission builds for. If the requirement is "this research task should run every Monday and land where the team can see it", the answer is often that your licence already does it, and the cost is somebody's afternoon.

OpenAI stated the boundary in its own developer documentation when we checked on 08 Aug 2026. You can trigger a workspace agent from another system, and in beta you can poll the run until it finishes. But "the agent's response cannot currently be retrieved through the API". You can start the work from your CRM. You cannot get the answer back into it.

So the test is where the output has to land. If a person reads it, a subscription may be enough. If the result has to be written into a system of record, reconciled, audited, or picked up by the next automated step, engineering starts. The three tiers of commitment are set out in what the OpenAI API does that ChatGPT cannot.

Build cost: five things move the number, and none of them is the model

Choosing a model is close to free. The build cost sits in the surrounding engineering, and five factors drive it.

How many systems it touches. Each system is an API, an authentication model, a rate limit, a test environment and an internal owner whose time you need. Two systems is not twice the cost of one, because the expensive part is what happens between them: which one wins when they disagree, what happens when one is down, and how you avoid writing the same record twice.

Whether those systems have a usable API. A documented modern API with a sandbox is a day of work to connect. A legacy or on-premise system with no test environment, no current documentation and nobody left who configured it is a different project, and often the largest single line in the quote. Establish this before you ask anyone for a price. It is knowable in an afternoon.

The state of the data. Covered on its own below, because for many businesses it is the whole first phase.

How much judgement the work needs. Pulling a purchase order number out of a document is close to deterministic and cheap to verify. Deciding which of your product lines a customer meant when they typed something approximate is judgement, and judgement costs money to build, to test and to correct. The example we can point to publicly is an AI order-entry agent we built for a UK builders' merchant, which reads incoming orders and writes them into the system. In any system of that shape, the reading is rarely the expensive part.

How bad a wrong answer is. This is the driver buyers underprice most consistently. If a wrong output wastes five minutes, you need very little around it. If it becomes a credit note, a mis-picked delivery or a regulatory report, you are paying for validation rules, confidence thresholds, a human approval step, an escalation path, logging you can reconstruct an incident from, and a way to reverse everything the system got wrong between Tuesday and Friday. None of that appears in a demo, and all of it separates a demonstration from something you put in front of customers.

Ask any supplier which of those five they have looked at. A quote that engages with none of them is priced on the happy path, and the happy path is not the job.

Running cost is set by OpenAI and shaped by whoever builds it

The usage bill is not ours to set or to quote. OpenAI charges API use per token, separately for input and output, with a reduced rate for input served from cache and a charge for writing to cache, and it offers different processing modes for work that is not urgent. ChatGPT Business seats are priced per user per month. Enterprise is quoted, and OpenAI offers credit-based and token-based pricing on that tier. Either way it is a separate bill from API usage. Rates move, so take them from OpenAI's own pricing page rather than from any article, this one included.

The shape of the workload is ours, and that is where the money is. Three engineering decisions, none visible in a proposal, separate a sensible bill from an absurd one for identical output.

  • Which model does which task. Prototypes are almost always built entirely on the most capable variant, because during a demo that is free and safe. Classification, extraction and routing generally do not need it.
  • What context repeats. Caching only pays if the stable part of the prompt is genuinely stable and comes first. A system that sends a slightly different opening every call pays the cache-write premium repeatedly and never earns the discount.
  • What does not need an instant answer. OpenAI's Batch API takes asynchronous groups of requests on a twenty-four hour turnaround, at a 50% discount against synchronous calls. Nightly enrichment and bulk document processing belong there. Only work a person is waiting for needs the immediate path.

This is why "what will it cost to run" cannot be answered from a brief. A badly shaped workload can cost several times a well-shaped one for exactly the same output, so two suppliers quoting the same build can leave you with running costs in different brackets, and nothing in either proposal will say so.

Do not accept a projection. Ask for a measured cost per transaction, taken from a real sample of your own data during discovery, modelled at three volumes: what you do today, what you plan to do, and the runaway case where something loops. Then set spend limits and alerts on day one, because the first surprising bill is usually a defect rather than growth. The engineering detail sits in what actually breaks between a ChatGPT prototype and production.

The cost everyone forgets is keeping it alive

A working system does not stay still, because four things underneath it move.

The vendor deprecates things. The dates are published. OpenAI's deprecations page, checked on 08 Aug 2026, has the Assistants API removed on 26 Aug 2026, the Videos API and the Sora 2 models removed on 24 Sep 2026, and Agent Builder, the Evals platform and reusable prompt objects all shutting down on 30 Nov 2026. Anything built on those has to be moved, whether or not it was working perfectly.

Models change. A new variant behaves differently on your edge cases. Without a saved set of test examples, a model change is an act of faith rather than an afternoon's verification, and building that test set afterwards costs more than building it at the start.

Your own systems change. Somebody renames a CRM field, an ERP upgrade alters a payload, a form gains a question. The failure that costs real money is not the one that throws an error. It is the one where the system carries on confidently with the wrong data and nobody notices for a month.

People leave. The engineer who built it, the manager who understood why, or the supplier's one person who read the deprecation notices.

Those notice periods are generous, and being told months ahead costs nothing. What costs money is that nobody was assigned to read the notice, so a scheduled change arrives as an outage. A system nobody maintains becomes an emergency on somebody else's timetable, at their date rather than yours.

Budget it as a standing line rather than a contingency: a support arrangement, or a named person internally with time in their week, and preferably both. Then ask the question where the ambiguity hides. Is a vendor-forced migration inside the support arrangement, or a new quote?

What makes a project cheap versus expensive

Locate yourself in this table before you read anyone's number. Most projects sit on both sides of it, and the rows on the right are where the quote goes.

CheaperMore expensive
One system, and the agent only reads from itSeveral systems, and the agent writes to a system of record
A documented modern API with a test environmentA legacy or on-premise system, no sandbox, no current owner
One authoritative record per customer, fields populatedDuplicates, half-empty fields, and the real answer in a spreadsheet
A person checks the output before it goes anywhereThe output acts on its own
A wrong answer wastes five minutesA wrong answer is a credit note, a complaint or a regulatory report
The scope is one task with an agreed definition of finishedThe scope is a process nobody has written down
You already run logging, environments and access controlThe project has to build the operating basics first
The work can run overnight in batchesSomebody is waiting for every answer

The first row is the one that changes the engineering category rather than the effort, because writing to a system of record brings approvals, reversibility and reconciliation with it.

For a lot of businesses the first real cost is fixing the data

Model quality is rarely the constraint in a mid-market business. The constraint is that the answer is not reliably present anywhere the model can reach it. Companies are duplicated, contacts sit against the wrong record, the fields that matter are half empty, product data lives in a spreadsheet on somebody's desktop, and the pricing actually charged lives in somebody's head. Point a model at that and you get answers of exactly that quality, delivered fluently and with total confidence, which is worse than no answer at all. How a workaround becomes a real integration, and when it should, is in replacing a ChatGPT workaround with a real integration.

That has a direct consequence for the number you are holding. Where two quotes are a long way apart, the usual explanation is not efficiency. It is that one has priced the data work and the other has assumed it away. The second number is not lower, it is incomplete, and the difference arrives later as change requests or as a system that quietly does not work. A supplier who quotes a build without examining your systems is quoting a figure they cannot stand behind, because there is no way to know what the data work costs without looking at the data.

One consolation, and it is real: unlike most of a build, the data work holds its value even if you never proceed.

How to sanity-check the number in front of you

Four checks, all of which you can apply to a document you already have.

Is it itemised? At minimum: discovery, integration priced per system, data work as its own line, validation and human review as its own line, deployment and environments, handover and documentation, and support. A single number on a single line is not a simpler quote. It is one where you cannot tell what gets quietly removed when you negotiate the price down.

Does the fixed price say what it includes? Named deliverables, testable acceptance criteria, an explicit out-of-scope list, a validity period, and a stated position on what happens to the price if the data turns out worse than assumed. Without those, a fixed price is a guess one party is contractually stuck with, and it resolves either as change requests or as work getting quietly thinner.

Does discovery produce something you own? The test is whether the document would still be worth the money if you took it to a different supplier or built nothing. What a discovery deliverable should contain, and the ownership terms to agree before signing, are set out in how to choose an OpenAI implementation partner.

Do these five questions get specific answers?

  • What is your estimate of the cost per transaction to run this, and what sample did you measure it on?
  • Which of our systems have you looked at, and what did you find in them?
  • What is in this number for data work, and what happens to the price if the data is worse than you assumed?
  • What proportion of the build is validation, review and error handling rather than the main path?
  • What would make you tell us not to do this?

The last is the most useful question in the list. A supplier who cannot name a circumstance in which they would advise against the project is not offering judgement.

Our own published numbers, and what they are not

Our fixed-price AI implementation packages are published on our AI implementation page and run from £8,000 to £45,000 depending on scope, on whichever platform the work lands. Our AI and Data Readiness Assessment starts at £5,000, with 20% credited against a subsequent implementation.

Those are our existing packages and they describe how we structure engagements. They are not a price for your OpenAI project. We do not publish an OpenAI price list, for the reason set out above: a number given before anyone has looked at your systems is a guess, and we decline to quote before we have seen the systems.

One structural point about running cost. Nothing we recommend earns us a margin on your platform spend, so you buy OpenAI subscriptions and API usage directly from OpenAI on your own contract. A supplier whose revenue rises with your consumption has no reason to argue for the smaller model, the cached prompt or the overnight batch.

Where this leaves you

You are deciding three things, not one: what to build, what it costs every month to run, and who owns it in a year. A quote that answers only the first is not cheaper than one that answers all three. It is less complete.

The next step costs nothing. Apply the workspace-agents test and see whether the requirement survives it. If it does, check the quote against the four sanity checks above, then put the five questions to whoever wrote it. The answers will come back at very different lengths, and that alone will do most of the sorting.

The wider comparison, including the options either side of this one, is in our guide to what OpenAI offers a UK business.

If you want ours, request a quote and we will tell you what we need to look at before giving you a number. Our OpenAI implementation work is scoped and priced in writing before you commit to anything.

John Kelleher

John Kelleher

Author
John is the founder and the Chief Executive at SpotDev.

Stay Updated with Our Latest Insights

Get expert HubSpot tips and integration strategies delivered to your inbox.