Machine learning development in Edinburgh
A model that comes out of an Edinburgh research group is usually right and rarely ready. It was trained on a lab dataset, runs from a notebook on a shared GPU, and depends on a PhD student who knows which cell to run first. Turning it into something a customer can rely on is a different job from the research, and it is where many spin-outs lose a year.
We do that job alongside the research team. We package the model behind an API, rebuild the data pipeline so training and serving compute features the same way, add monitoring for drift and failure, and set up retraining that someone other than its author can run. The science stays with the people who understand it. We took repeat-fault clustering on FM360 from experiment to production in the same way.
Edinburgh is a money town with a major research university in the middle of it, and its software work reflects both. On one side sit the fund managers, life and pensions firms and banks: Baillie Gifford, NatWest Group's headquarters at Gogarburn, and a long tail of platforms, administrators and wealth managers. On the other side sit the University of Edinburgh's informatics and data science groups, and EPCC, which hosts the national supercomputer ARCHER2 and was chosen in 2025 as home for the next one, with up to £750 million of government funding.
The financial side needs systems that are careful rather than fast. Pension and investment products carry decades of rules, and much of the administration runs on platforms that predate the people maintaining them. Customers expect to see their pot, their charges and their options clearly on a screen, and advisers expect the platform to answer as fast as the one they used yesterday. So the work is usually integration, data, reporting and customer screens around an old core, with every change tested before it ships. Fintechs sit in between, often selling back into those same banks and fund managers.
The university side needs something different: research code that works on a GPU in a lab and has to become a product that works for a paying customer. That gap, between a model that is right and a service that is reliable, is where many spin-outs stall. Hiring is competitive. ITJobsWatch puts the median advertised software engineer salary in Edinburgh at £70,000 over the six months to September 2026, on a smaller sample than London, and the banks and fund managers take many of the experienced engineers.
Working with us from Edinburgh fits the day you already have. Four hours of every working day overlap with yours, set across your morning, so stand-up, review and the decisions that follow happen live with the engineer who writes the code. The rest of the day runs on written updates and pull requests in your own Slack, GitHub and Linear, waiting for you after lunch, with runbooks and architecture notes written as the work goes.
We are the right fit for a defined piece of work, a spin-out's first production system, or a project that needs senior engineers this quarter while your own hiring catches up. Start with a fixed-price two-week piece and judge us on what ships. For agencies, we work white-label under your name, in your repositories and tools.
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 Edinburgh teams.
How do you work with teams in Edinburgh?+
Four hours of every working day overlap with yours, set across your Edinburgh morning, so stand-up and code review 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 rest of the day carries on in pull requests and written updates that are waiting for you after lunch, with runbooks and architecture notes written as we go.
Do you build for Edinburgh fund managers and pensions firms?+
Yes. For pensions and investment platforms we build services around the administration core: APIs that expose what it knows, transfers and switches processed exactly once, and tools for the exception cases that live in spreadsheets today. For fund managers we build investment data pipelines that trace every figure back to its feed, research search that cites its sources, and customer screens that make pots and charges clear.
How does your rate compare to hiring in Edinburgh?+
ITJobsWatch puts the median advertised salary for a software engineer in Edinburgh at around £70,000. Our published rate is $35/hour with a $5,000 minimum, or $5,400 a month for one engineer embedded in your team. There is no recruiting time and no employment overhead, and we can start within days of the first call. A fixed-price two-week piece at $2,800 lets you judge us on output first.
Can you work with a university spin-out?+
Yes, and it is a good fit. Spin-outs usually have strong research code and nobody whose job is running it in production. The research team stays in charge of the science, and we build what surrounds it: the API, the data handling, the deployment and the monitoring. A fixed-price two-week piece fits a grant or accelerator budget, and the code belongs to the company from the first commit.
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.