AI software development
We build AI into software when there is a job for it. The job is usually one of three things: a decision a team makes thousands of times a week against written rules; a photograph, a voice or a sensor reading that a person currently turns into data by hand; or the building of the product itself. This page covers all three, with the projects behind each.
We have built software for established UK businesses since 2011, and AI is one of the tools inside that work. The people who scope, design and build your system are the ones deciding where a model belongs in it, and where a plain rule does the job better. Every project starts with a discovery, at no upfront cost, and that is where the decision gets made.
Three things we do with AI
Automating a decision a team makes all day
Illingworth Research Group pays the expenses of patients on clinical trials in 36 countries, and its team was approving every claim by hand, reading each one against more than a hundred different expense policies. We built the approval into PatientGo, the platform we run for them: the system reads the claim, checks it against the policy that applies and approves the 90% that are clear-cut. The doubtful 10% go to a person, with the reason flagged. The team went from 500 claims a week to 5,000 with no extra headcount. Read the PatientGo case study.
Work like this goes live in weeks, because it replaces one process at a time. The next process follows once the first has paid for itself. Where the process sits inside a wider system, that system is usually the kind we build on the business systems page.
Putting AI inside a product
Using AI to build better software
We use AI throughout our own work: prototyping faster, throwing more options away before committing, writing more tests, and catching more in review before anything reaches staging. The result for a client is a better product on a similar budget, or the same product sooner. There is no AI discount, because every line a model produces is reviewed by a senior engineer who knows what a security flaw looks like in your stack, and that review is what you are paying for. The evidence behind that position is in our post on what AI has done to software development cost.
When AI belongs, and when it does not
Most AI features fail because they were added to a product first and given a job afterwards. We start from the job. AI goes in when...
When it stays out
We will tell you which side of that line your idea sits on in the discovery, before anything is built. The longer argument is in our post "Should you add AI to your app? Most shouldn't bother"
How an AI build works
- Discovery, at no upfront cost. We map the process or the product, find where a model belongs and where it does not, and put a scope in front of you. It is yours to keep whether you build with us or not.
- The job and the data. We define what the system decides, what it hands to a person, and what data it works from. If the data is not there yet, that is the first build.
- A working version on real data. A first version runs on your live data within weeks, with a person on every doubtful case from day one.
- Measured against a target. Approval rate, hours saved, records completed: whatever the job was, it gets a number and the system is tuned against it.
- Then the next one. Once the first process has paid for itself, the second is usually obvious.
Projects that speak for themselves
Common questions
A single process, such as approvals or document handling, is usually live in weeks. AI inside a product takes the product's timeline, and the AI part is rarely what sets it. We put a timeline in writing at the end of discovery.
Start with a discovery
Every project we take on starts with a two-week discovery run by our senior team, at no upfront cost. You point us at the process or the product, we work out what is worth building and whether AI belongs in it, and you get a documented scope that is yours whether you build with us or not.