A large share of the software work commissioned around Cambridge begins as something that already exists: a script that a scientist wrote, a model that works on one machine, a prototype built by a founder who has since moved on to fundraising. The buyer is rarely starting from nothing. They are asking a supplier to turn research-grade code into something a customer, a regulator or an investor can rely on, without losing the behaviour that made it valuable.
That framing changes which supplier you want and which contract you sign. The profiles on our software development directory will give you candidates; the sections below cover what to test before you commit a budget.
Turning research code into production software is a distinct purchase
Rewriting a working prototype is not the same job as building a new system, and suppliers price it as though it were. The awkward truth is that the prototype encodes decisions nobody wrote down: tolerances, edge cases, a fix applied during an experiment two years ago. Throwing it away destroys that knowledge, and preserving it wholesale produces something unmaintainable.
Ask candidates how they would establish equivalence between the old behaviour and the new system. A capable supplier will describe a characterisation suite built from real inputs and known outputs before any refactoring starts, and will treat the original author's time as a project dependency to be scheduled. A supplier who answers with a technology stack has not understood what you are buying.
Insist that the first milestone is a reproducible build and a test harness rather than a feature. It feels like slow progress and it is the only thing that makes the rest of the estimate meaningful.
Intellectual property gets complicated before anyone writes code
Where a company has emerged from a research institution, ownership is usually layered: background rights held by the institution, foreground rights created under a licence, and now a third party contributing new material. A standard supplier contract assigning everything to the client can conflict with the licence you already signed.
Bring the agreement to the table early and ask the supplier to accept assignment language that survives it, including a clause covering contributions from subcontractors and part-time contractors. Where a supplier proposes reusing its own framework or libraries, get the licence terms for that reuse in writing, with a perpetual and transferable grant, because an acquirer's lawyers will find it even if you do not.
Open source obligations deserve the same attention. Ask for a dependency inventory with licences at each release, not a promise that everything is permissive.
Buying machine learning work without buying a demonstration
Search demand around Cambridge for artificial intelligence consultancy has grown faster than the number of suppliers who can put a model into production and keep it there. A convincing demonstration is cheap to produce and tells you almost nothing about operating cost, failure behaviour or drift.
Structure the engagement so that evaluation comes before commitment. A short paid phase should deliver an honest baseline, a held-out evaluation set that you keep, an error analysis that describes where the approach fails, and a written recommendation that includes the option of not proceeding. Suppliers who cannot lose the follow-on work are not incentivised to give you that recommendation, so say plainly that the assessment is a deliverable in its own right.
For production work, ask who is responsible for monitoring quality after launch, how retraining is triggered and paid for, where inference runs, and whether any customer data leaves your environment to reach a third-party model. Those four answers determine your ongoing cost more than the day rate does.
A small supplier pool competing for the same engineers
The constraint in this market is people, not demand. Software suppliers compete for the same senior engineers as well-funded product companies and research institutes, which produces two visible effects on proposals. Teams are assembled partly from contractors, and the named senior engineer is often allocated across several clients.
Neither is disqualifying, but both should be explicit. Ask what percentage of the proposed team is employed by the supplier, what notice period applies to a replacement, and what proportion of the lead engineer's week your project actually receives. Ask what happened the last time a key person left mid-project and what the client paid for the transition. Vague answers here reliably predict the problem you will have in month six.
Written knowledge is the defence. Require that architecture decisions, environment setup and operational runbooks are committed to your repository as work progresses, and treat their absence as an unfinished deliverable rather than documentation debt.
Fee structures and the milestones that go with them
Grant and investor funding arrives in tranches, so buyers here often want fixed prices to match a reporting cycle. Fixed price works where scope is genuinely known, which usually means a migration, an integration or a well-specified compliance piece. For discovery-heavy work it converts every learning into a change request.
A practical middle path is a capped time and materials arrangement with milestone reviews aligned to your funding events: you keep the flexibility, the supplier keeps the honest estimate, and the cap gives your board a number. Ask for weekly burn against the cap, in writing, from the first week rather than the first problem.
Whatever the structure, separate build cost from run cost in the quote. Hosting, monitoring, third-party services and support after launch are the figures most often missing from a comparison, and they are the ones that persist.
Comparing suppliers in Cambridge without wasting a quarter
Write one brief that describes the business problem, the constraints you cannot change and the evidence you will accept as proof of success. Send it to a handful of candidates with the same deadline. Judge the replies on the assumptions they surface and the risks they are willing to name, because a supplier who cannot tell you what might go wrong has not thought about your project yet.
Ask for a reference client whose project ended, not only one that is running. The conversation you want is with a buyer who has been through handover, renewal or exit.
When the shortlist is ready, request comparable proposals so that every supplier answers the same brief on the same timetable. If your immediate need is a customer-facing product interface rather than a system, the web design agencies listed for this market cover a different set of firms, and communications support for a launch sits with public relations agencies. Buyers extending their search often compare Bristol or Leeds suppliers alongside local ones.
Questions to ask before hiring a software company in Cambridge
Is a specialist scientific software supplier worth the premium?
If your system is mainly ordinary software wrapped around a small novel core, a strong general supplier plus access to your own experts is usually better value. If the domain itself is hard, for instance instrument control, simulation or regulated analysis, the premium buys you a supplier who will not rediscover known problems at your expense.
How do I keep control of a project when my team is two people?
Own the accounts, own the repository, insist on written decisions, and book a fixed weekly slot that you never cancel. Control comes from artefacts and attention rather than from headcount.
What should a discovery phase produce?
A data model, an integration list with named owners, a risk register, a test strategy and an estimate expressed as a range. If the output is a presentation, you bought a sales meeting.
Can I move a project to another supplier later?
Yes, if you prepared for it: your repository, your infrastructure accounts, documented environments, and a contractual transition clause with paid handover hours. Without those, switching costs roughly as much as the original build.