One of the biggest warning signs for me is when a conversation starts with the technology rather than the problem: “We need an AI agent” or “We want to put AI into our product”, without a clear account of what needs to improve.
When that happens, our first job is to understand the operational or commercial problem. A polished AI demo can now be produced quickly. The more important question is whether it solves something valuable enough to justify building, integrating and supporting it properly.
That distinction matters when choosing a UK AI implementation partner. An enterprise consultancy, a specialist machine learning firm and a software engineering company may all offer credible AI services, but they solve different kinds of problems. If you need AI to work with existing systems, data and workflows, the model is only one part of the implementation.
The right partner is the one whose experience matches the change you are trying to make, from identifying a worthwhile opportunity through to operating the resulting software in practice.
Start with the kind of partner you need
There is no single category of company called an AI partner. Most organisations considering custom AI work will encounter three broad types of supplier.
Enterprise transformation consultancies
These are strongest when AI forms part of a large organisational programme involving multiple departments, major technology vendors, governance, procurement and substantial changes to how people work. Their scale can be valuable, although software delivery may be one workstream within a much larger engagement.
Specialist AI and machine learning firms
These teams are often the right choice when the central challenge is technically novel: custom model development, computer vision, forecasting, optimisation or advanced data science. Their depth may be concentrated on the model rather than product design, business-system integration and long-term software ownership.
Software-engineering-led AI partners
These are well suited to work where AI needs to become part of an existing product, staff workflow or operational platform. The surrounding work usually includes permissions, interfaces, integrations, business rules, data quality, exceptions, monitoring and support. The AI matters, but it has to work as part of a complete service.
There is also a sensible fourth option: do not commission custom software when an established product already solves the problem well. A credible partner should be willing to recommend that.
AI transformation does not have to mean a large, multi-year enterprise programme. For an SME, it may be a focused engagement to identify the right opportunities, test them against the way the business works and create a practical route to adoption or delivery.
Five questions to ask an AI implementation partner
Whichever kind of partner you need, production AI means more than connecting a model to a live application. It has to work as part of a product, service or business process that people rely on, with the data, permissions, integrations, monitoring and support that requires. Here are five questions to consider when selecting a partner.
1. Are they solving a worthwhile problem?
A good partner should begin with the outcome rather than a preferred model or agent framework. They should want to understand the current workflow, the people involved, where time or money is being lost and what a better result would look like.
Our recent work with Take Me to the Moon is a useful example. The specialist travel company initially approached us with the idea of an AI itinerary builder. We challenged that direction because basic itinerary generation is increasingly commoditised and, on its own, did not reflect what made the business valuable.
Its real advantage is human expertise, local knowledge and reassurance. We therefore explored how AI could strengthen that service: capturing richer information from prospective travellers, using existing knowledge and previous journeys to accelerate planning, and handing the work to a human concierge. That led to a broader product direction for a travel companion that could remain useful throughout the customer journey.
For me, that is what AI transformation often looks like in practice: understanding the wider business and customer journey, then asking whether something should be built as well as whether it can be built.
2. Can they show what happened after the prototype?
A prototype is valuable because it helps test an idea quickly. It is not evidence that the complete system will work with genuine users, imperfect data and existing business processes.
Ask what reached operational use, what changed after testing or launch, how quality was assessed and who owns the next stage. Useful evidence might include a product now used by clients, an AI feature integrated into an established platform, a validated technical approach or research that is progressing into operational tooling. The supplier should be clear about which stage each example has reached.
Brace for Impact shows one form of evidence. Working with ImpactIO, we explored how AI could help organisations interpret sustainability evidence while keeping outputs grounded in the source material. The resulting platform reduced work that had taken hours or days to minutes, produced more consistent analysis and created a new commercial opportunity for the client.
Emvelo shows another stage of the journey. We re-engineered high-resolution data from more than a thousand sensors, created a digital twin of a 100MW solar plant and tested optimisation strategies for improving evening energy output. The research produced promising findings and a validated foundation; the next stage is an operational web application for plant operators. Being precise about that distinction is part of credible delivery evidence.
3. Can they engineer the systems around the AI?
For many projects, this is the decisive question. The supplier may need to connect AI to customer records, documents, identity providers, databases, APIs, background processes or existing operational platforms. It must understand what information the model needs and what actions it is allowed to take.
Ask which parts of the proposed system will use model judgement and which will remain deterministic. An agent that needs to update one case should receive a narrow action designed for that purpose, with validation and permissions built in. It should not receive broad access to the underlying database.
The quality of the surrounding software determines whether an AI capability is useful outside a demonstration. Data structure, workflow exceptions, user experience and support arrangements all shape how it behaves in everyday use.
4. Can they evaluate, monitor and control it?
One useful way to assess this is through the context, constraints and control framework we use when designing production AI systems. Context is the information the system needs. Constraints define what it can and cannot do. Control covers evaluation, monitoring, human review and rollback. Jamie Matthews explains the framework in The Three Cs of Production AI.
Claims such as “95% accurate” mean little without context. Ask what was measured, who judged it, whether some errors matter more than others, and how behaviour will be checked when prompts, data, tools or models change. The partner should also explain what happens when the system is uncertain or wrong.
For UK organisations, this also sits alongside legal and security responsibilities. The ICO’s AI and data protection guidance takes a risk-based approach, while the National Cyber Security Centre’s secure AI guidance covers secure design, development, deployment and operation. A UK partner should be able to apply those principles proportionately to the product and data involved.
5. Who owns and supports the result?
Ownership and support should be discussed before development begins. Clients should understand who controls the source code, infrastructure, product data, prompts, evaluation material, integration credentials, logs and technical documentation.
Complete portability is not always realistic, but unnecessary dependence on one supplier, model or service should be avoided. The partner should explain what changing provider would involve and how knowledge will be transferred.
Meet the people who will do the work, not only the sales team. Establish who will make product, architecture, data and security decisions, how senior people will remain involved and who will support the system after release.
Questions to use in a supplier conversation
- What problem or outcome should this work improve, and how will we measure the change?
- What comparable work has reached genuine users or operational use?
- What changed after the prototype was tested?
- Which parts of the system will use AI, and which will remain deterministic?
- What data and operational systems will the AI be able to access?
- How will evaluation, human review, monitoring and rollback work?
- What will we own, and who will support the system once it is live?
Specific answers matter more than sophisticated terminology. A good partner should be comfortable discussing limitations, failed assumptions and circumstances in which AI is not the right answer.
Where DabApps fits
DabApps is a UK AI implementation partner combining AI transformation, product strategy, design and software engineering. We are a strong fit for SMEs and product teams that need to identify where AI could make a measurable difference, shape a practical first initiative or integrate it into an existing product, workflow or body of data.
That can mean challenging the initial idea, as we did with Take Me to the Moon; integrating AI into a data-heavy platform, as with Brace for Impact; or preparing complex operational data and models for a tool used by specialists, as with Emvelo.
We also provide practical AI engineering training for organisations that want their own development teams to adopt coding agents safely and consistently.
We bring more than 15 years of experience building and supporting production software to that work. Most of it involves the same foundations AI systems still need: permissions, business rules, integrations, user interfaces, auditability, deployment and long-term maintenance.
We are less likely to be the primary partner for a global transformation requiring delivery across many countries, or for research focused on training a new foundation model. We also will not recommend custom development when a suitable product already addresses the need.
DabApps is a member of the OpenAI Partner Network, giving our team access to OpenAI resources, enablement and technical support. We see that as useful supporting evidence, not a substitute for delivery experience.
Choose the partner around the problem
The strongest AI opportunities are normally the ones where you can explain the value without mentioning AI. Perhaps a staff process takes too much time, customers are dropping out at a particular point, or better use of existing data could improve a decision.
Once that problem is clear, it becomes much easier to choose the right partner. Use a transformation consultancy when organisation-wide change is the main challenge. Use a specialist AI firm when the model or data science is genuinely novel. Use a software-engineering-led AI partner when AI needs to become a reliable part of a product, workflow or operational system.
The best early conversation is not about which model to use. It is about what needs to work, who will rely on it and what evidence would justify taking the next step.