AI software development

Three things we do with AI

Businesswoman presenting a Q4 growth bar and line chart to two seated colleagues at a modern desk.Businesswoman presenting a Q4 growth bar and line chart to two seated colleagues at a modern desk.

Automating a decision a team makes all day

A suitable AI workflow starts with a repeatable decision, usable source data, a clear confidence threshold and human review for uncertain cases.

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

01
AssetSnap needed building surveys that an engineer, or an apprentice in their first week, could do. The app photographs an asset, image recognition identifies it and fills in the record, and a person checks it before it goes into the client's CAFM system. Total project time fell by two thirds, measured by the client on live surveys. Read the Asset Snap case study.
02
Swigable's smart bottle had to tell a real sip from a bottle knocked over or swung in a bag, from tilt alone. The measurement runs on machine-learning models built from academic data on how people drink, so it judges the volume of a real sip and rejects everything that is not one. Read the Swigable case study.
03
Voice-Care put compliance reporting on a headset. Clinicians talk through the checklist in theatre or at the bedside, the system completes the record hands-free, and every use produces a compliance report straight into the back-office system. On trial at 8 NHS Trusts, and a Healthtech Digital Award winner in 2023. Read the Voice-Care case study.
Silhouetted group in business meeting with two men shaking hands against yellow background.Silhouetted group in business meeting with two men shaking hands against yellow background.
Purple 3D humanoid robot figure on a light purple background, raising its right hand as if waving.

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 important control is review: generated code must meet the same security, testing and maintainability standards as any other implementation.

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...

0
1
The task is high-volume and repetitive
0
2
It is pattern-heavy: reading, matching, classifying, recognising
0
3
A small error rate is survivable, or a person sits on the doubtful cases
0
4
You can say in one sentence what it replaces and why the AI version is better
0
1
A fixed rule already does the job. A rule is cheaper to run, easier to test and never drifts
0
2
A wrong answer is dangerous and nobody is in the loop to catch it
0
3
The feature exists because a competitor has one, and no user has asked for the job it does
0
4
The product has not yet found the users whose work it would change

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 decision should be documented before a model becomes part of the product or process.

How an AI build works

  • Discovery and scope. 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.
Man wearing glasses sitting at desk viewing two monitors, one showing code and the other a media app.

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.

Yes. Integration requirements should be assessed early, including ownership, authentication, rate limits, failure handling and audit needs, and every Voice-Care checklist lands as a compliance report in the back-office system. We build to your systems, and where a system has no way in, we say so in discovery.
It is designed for from day one. Every system we build has a person on the doubtful cases and a record of what was decided and why. The expense system approves the 90% it is sure of and flags the 10% it is not. A model that is wrong two per cent of the time is fine when a person sees those cases and dangerous when nobody does, so we do not build the second kind.
Your data stays your data. Where it is held, which models see it and on what terms are agreed in discovery and written into the scope, and we build to the data-protection obligations your sector already carries.
They will, and the system is built so that they can. The model sits behind an interface we control, the tests that prove the system does its job run against every change, and swapping a model is a maintenance task, not a rebuild.
Yes, on the same arrangement as any system we build: monitoring, fixes, model and dependency updates, and the changes that come once a team has used it for a month.
We work with established businesses, usually with a team whose time is going into a process that has outgrown the way it is done. If the process is small enough to fix with a spreadsheet, we will say so.

Start with a discovery

Projects begin with an agreed discovery and scoping stage proportionate to the uncertainty involved. 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.

Book a discovery