Machine learning development in Birmingham
A West Midlands production line already produces most of the data a quality model needs: machine readings, inspection results, scrap records and maintenance logs. What it rarely has is anyone joining them up. The result is familiar: the same fault recurring on the same machine, noticed by the operator who has seen it before and missed by everyone else.
We build models on that data: early warning when readings drift towards a known failure, grouping of recurring faults so the root cause becomes visible, and predictions placed where the maintenance planner or the shift lead will see them. On FM360 we took repeat-fault clustering from an experiment to production for a facilities team, and the lesson was that engineers trust a group only when they can see why its members belong together.
Birmingham's software buyers are mostly not software companies. The city runs on financial and professional services: HSBC UK's head office at Centenary Square, the Birmingham office Goldman Sachs opened in 2021 with a technology focus, and the accountancy and law firms around Colmore Row and Snowhill. What they bring us is internal systems rather than consumer products: client portals, case and matter management, reporting that currently takes a week of spreadsheets, and integrations between platforms that different departments bought at different times.
Construction, transport and manufacturing make up the rest. HS2's Curzon Street terminus and the regeneration around it keep engineering consultancies, contractors and their supply chains busy, and those firms run on drawings, inspections, documents and project controls spread across too many tools. Manufacturing brings its own lesson. The 2025 cyber attack on Jaguar Land Rover stopped production at its West Midlands plants for weeks and reached deep into the supplier base, and suppliers now want business systems they can restore quickly and integrations that pick up cleanly when they come back.
The city has also watched its council's Oracle programme. The Register reports a forecast cost of £144.4 million against an original estimate of around £19 million, with the finance system still not working as intended. The lesson local buyers draw is the right one: customise less, test the money flows before go-live, and keep the people who use the system in the room. Hiring is competitive but cheaper than London, and the banks and professional firms compete for the same engineers. ITJobsWatch puts the median advertised salary for a software engineer in Birmingham at £70,000 over the six months to September 2026.
Working with us from Birmingham needs no adjustment on your side. Four hours of every working day overlap with yours, set across your morning, so stand-up and the decisions that follow happen live with the engineer who writes the code. The afternoon runs on written updates and pull requests in your own Slack, GitHub and Linear, with runbooks and architecture notes written as the work goes.
We are the right fit for a defined piece of work: an integration, a replacement for the spreadsheet, a portal with a deadline, or the groundwork before your own hire starts. We add senior capacity within days, begin with a fixed-price two-week piece so you can judge the output, and work white-label under your name for agencies.
Four ways this arrives.
Someone got good results on a laptop and nobody can reproduce them. We turn it into a training pipeline with pinned data and versioned artefacts, put a serving endpoint in front of it, and record what it was evaluated on so the next version can be compared.
Hundreds of conditions routing tickets or flagging risky orders, each added after an incident. We measure what the rules get wrong on your labelled history, then test whether a classifier beats them. Sometimes the answer is fewer, better rules, and we say so.
Demand, load or staffing estimates that miss often enough to be ignored. We start with a plain seasonal baseline, backtest against the periods you actually plan around, and add complexity only where it beats that baseline on those periods.
Duplicate records, recurring faults, near-identical products under different names. Embeddings group text by meaning where keyword matching cannot, and we build the screen that lets a person correct a group rather than trust it blindly.
Repeat-fault detection that began as UMAP and HDBSCAN over 33,000 work orders and shipped as nightly incremental clustering on the same embedding model.
Read the write-up →Asked by Birmingham teams.
How do you work with teams in Birmingham?+
Four hours of every working day overlap with yours, set across your Birmingham morning, so stand-up and the day's decisions happen live. We join your calls and work in your tools: Slack, GitHub and Linear. You talk directly to the engineer who writes the code. The afternoon carries on in pull requests and written updates you can read when you are back at your desk, with runbooks and architecture notes written as we go.
Do you build for Birmingham law and accountancy firms?+
Yes. For the firms around Colmore Row and Snowhill we build client portals that work on a phone and ask for each piece of information once, matter and case management tools, and reports that assemble themselves instead of taking a week of spreadsheets. For accountancy practices we build AI features that pull figures from bank statements and receipts, suggest categories and put the result in front of an accountant to approve.
How does your rate compare to hiring in Birmingham?+
ITJobsWatch puts the median advertised salary for a software engineer in Birmingham at around £70,000. Our published rate is $35/hour with a $5,000 minimum engagement. There is no recruiting time and no employment overhead, and we can start within days of the first call. Most clients begin with a fixed-price two-week piece at $2,800, which lets you judge us on working software before committing to more.
Should we replace our ERP or build around it?+
Usually build around it, at least first. Birmingham has seen what heavy customisation can cost. Most of the pain sits in the gaps between an ERP and the rest of the business, and every customisation makes the ERP harder to upgrade. We build small tools alongside it that talk to it through supported interfaces. If replacement is genuinely the answer, we will say so and set out what to test before go-live.
Do we need machine learning, or is a rules engine enough?+
Often a rules engine is enough, and it is cheaper to run, explain and audit. If the people who make the decision today can write it down, write it down. A model earns its place when the rules keep multiplying, the inputs are messy text or images, or the pattern shifts faster than anyone can edit the rules. We check against your history before recommending either.
Why not just call a hosted model API?+
Sometimes you should. With low volume, messy language and no labelled data, a hosted model and a good prompt ship quickly. A trained model wins when per-call pricing starts to hurt at your volume, when latency matters, when data cannot leave your systems, or when you have labelled examples a small model can learn from. We price both paths before you commit.
How much data do we need?+
For classification, usually fewer labelled examples than people fear, and embeddings can group text with no labels at all. Forecasting is the opposite: you need enough history to cover the cycles you plan around, and a single year says little about a yearly pattern. We give you an answer after looking at your data, not before.
What happens when the model gets worse?+
It will, because the world it learned from changes. We log inputs and predictions, compare them with outcomes as they arrive, and alert when accuracy or the input mix drifts past a threshold you agreed. Retraining is a scripted pipeline with an evaluation gate, so a new model replaces the old one only when it does better on the same test set.
Can you build a recommendation system?+
Yes, and we would start without a learned model. Co-occurrence and embedding similarity, served from Postgres or a vector index, beat a most-popular list for most catalogues and are easy to debug. A learned ranker comes after that, once you have enough interaction data to train and evaluate one. A learned ranker is something we build from our work with embeddings and clustering, starting from a simple baseline you can measure it against.