How to choose an OpenAI implementation partner in the UK

You have three firms on a shortlist. All three are credible, all three have a badge somewhere in the deck, and the three documents in front of you are not comparable with each other. One is a day rate. One is a fixed price arrived at after a single call. One is a phase one, with the interesting parts in a phase two that has no price on it.

That is the real problem at this stage of the decision, and it is not a credentials problem. Credentials sort the pile, and we have written separately about what an OpenAI partner badge proves and how to vet a supplier's credentials. Assume you have done that and the shortlist survived it.

This is about everything after the shortlist: how the work should be shaped, how it should be bought, and what a good engagement leaves behind. We sell this work, so read it as a supplier telling you which questions make suppliers uncomfortable.

Fixed price and time and materials pay for opposite behaviours

Both are legitimate. They put the risk in different places and reward different things.

Time and materials is not cheaper or dearer. It moves the management job to you, and most mid-market businesses do not have a spare person with both the availability and the technical judgement to direct a supplier weekly. The ones who assume they do find out in month two.

The trap on the other side is more common. A fixed price is only as good as the scope document behind it. A price quoted off a discovery call is not a fixed price, it is a guess one party is now contractually stuck with, and it resolves one of two ways: the supplier absorbs the loss and the work gets quietly thinner, or the change requests start. Neither is what you bought.

A discovery phase protects the buyer more than the supplier

The way out of that is to buy the scope before you buy the build. A short, paid, fixed price discovery or assessment, delivered as a document, with the build priced at the end of it.

That sounds like a supplier upsell. It is not, because it costs the supplier something real: a firm that insists on discovery gives up the ability to win a large build on optimism, and can no longer put a confident number on a project it has not examined.

What you should get for the money is specific:

• What will be built, in enough detail that a different engineer could build it.
• Which systems it touches, and what state those systems are actually in.
• What it will cost to run, not just to build, at your expected volume.
• The risks, including the ones that would stop the project.
• A fixed price for the build, valid for a stated period.

Apply one test to the result. If you took that document to another supplier, or decided to build nothing, would it still be worth what you paid? If the answer is no, you did not buy a discovery, you bought a sales document with a fee attached. You also find out cheaply how the firm writes, whether it hits a date, and whether it asks about your data or only about your ambition.

Own the code, the contract and the documentation, or you own a login

The failure mode here is common and rarely comes from bad intent.

A supplier builds your system on their own OpenAI account, in their own repository, sometimes on their own hosting. It works, it is quick, and it is how a small firm gets to something impressive fast. What you receive is access: a login, a URL, maybe an admin panel. That is fine until you want to renegotiate, change supplier or take the work in-house, at which point you find you own nothing that runs.

Write the ownership position into the contract before work starts. Retrofitting it costs money and goodwill.

• The code sits in your repository, under your organisation's account, with its history intact. Not a zip file at the end.
• The vendor contract is in your company's name. You hold the OpenAI account, the billing and the admin, which for a UK customer means your own Data Processing Addendum with OpenAI rather than sitting underneath your supplier's.
• The data stays in your systems. If the useful output only exists inside the supplier's environment, you have created a second system of record you do not control.
• The documentation is written for a stranger. What it does, what it calls, where the prompts live, where the secrets live, what to do when it fails at two in the morning.
• You can revoke access in an afternoon and the system keeps running. That is the single cleanest test of whether the handover was real.

None of this is hostile to a good supplier. Our contracts put the code in your repository and the vendor account in your name.

A supplier who takes a margin on your usage earns more when you consume more

If a firm resells licences to you, or takes a percentage of your model spend, then their revenue rises with your consumption. That is not dishonesty and it does not make their advice wrong. It is a conflict, and it should change how you read three specific recommendations:

• Which tier they put you on. The gap between the paid organisation tiers is a governance question with a price attached, and you want that recommendation coming from your requirements rather than from a margin.
• Architecture decisions that move consumption. How much context is sent on every call, whether repeated context is cached, whether a smaller and cheaper model would do. These are invisible to a non-technical buyer and they move the running bill considerably.
• Whether you need the build at all. A supplier with a margin on usage has no reason to tell you the work is already covered by software you pay for.

Ask the question directly, in writing: do you resell licences, do you take any margin on our usage, and are you paid by any vendor for placing us on their platform.

For the record, SpotDev resells nothing and takes no margin on usage. You buy your OpenAI subscriptions and API usage directly from OpenAI, on your own contract, and we charge for the engineering. There is a related conflict worth naming in ourselves: a firm that builds on one platform keeps finding that the answer is on that platform. We are an OpenAI Select Partner, deepest on Anthropic's Claude, and a HubSpot Diamond partner, with no default. Sometimes the answer is the AI already included in software you pay for.

"Done" means production, not a demo

A demo works when the person who built it is driving. Production means it works when nobody is watching. Get the acceptance criteria written down before you sign, as statements you can test:

• Logging. You can see what it did, on what input, when, and what that cost.
• Monitoring and alerting. Somebody finds out that it has stopped, or started failing quietly, without a customer telling you.
• A named owner inside your business. Not only at the supplier. If nobody in your company owns it, it is an orphan on day one.
• A handover done with the people who will operate it, not a document emailed on the last day.
• An answer to platform change. Specifically: who watches vendor deprecation notices, and is a forced migration inside the support arrangement or a new quote.

That last point is concrete, not hypothetical. OpenAI is retiring the Assistants API on 26 Aug 2026. AgentKit's Agent Builder and its Evals both shut down on 30 Nov 2026, with Evals going read-only on 31 Oct 2026. Anything built on those needs moving. The notice went out months in advance, which is fair, and it helps you not at all if the only person who read it left the supplier last year.

The warning signs, described properly

These are things you can observe in a proposal or a meeting, rather than adjectives.

No named production reference. Ask what is running right now, who operates it, and whether you can speak to them. Pilots, prototypes and strategy engagements are real work, but they answer a different question. For our part, 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.

A proposal with no data quality work in it. If nobody has asked about duplicate records, empty fields, or which system holds the authoritative version of a customer, then nobody has looked at your systems, and the estimate is a guess dressed as a quote.

A fixed price with no discovery. Someone is going to lose money on that number, and the mechanism for recovering it already exists in the contract.

A supplier who has never had to migrate anything. The 2026 deprecation schedule gave everyone plenty to answer with. A firm with systems in production will have a specific and slightly weary account of what they moved and when. A blank answer means either nothing is in production or nobody was watching.

An unwillingness to say when you do not need them. Ask what would make them recommend against the project. If every problem resolves to a build, you are buying their business model rather than their judgement.

For most businesses the first project is the data, not the model

This is the finding most proposals leave out, and the one most likely to decide whether your project works. Model quality is rarely the constraint in a mid-market business. The constraint is that the answer is not reliably present in any system the model can reach. 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 real pricing 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 getting no answer at all.

A supplier who cannot say this to you has either not looked at your data or would rather not, because "the first phase is fixing your CRM" is a harder sale than an agent demo. It is also, often, the accurate sequence. This is why we run AI implementation on a model neutral basis and why data foundations sit inside our OpenAI implementation work rather than being treated as somebody else's problem.

The decision in front of you

You are not choosing a badge, and probably not a technology either. You are choosing four things, all of which you can get in writing before committing significant money: how the work is scoped, what you own on the last day, whose revenue moves when your usage moves, and what "done" means as criteria you can test.

So ask every firm on your shortlist for their discovery deliverable, their ownership terms and their acceptance criteria. The answers will come back at very different lengths, and that alone will do most of the sorting.

This is one rung of a longer ladder, set out in our overview of OpenAI for UK business.

If you want ours, request a quote and we will put the scope, the ownership terms and the price in writing before you commit to anything.