Codethink works where software stops looking like an app and starts looking like a small country. There are borders between chips and kernels, trade agreements between suppliers, ancient roads no one dares close and a customs queue every time somebody ships an update. The Manchester company designs and repairs that territory: firmware, drivers, board support packages, operating systems, middleware, build machinery, test systems and the long maintenance tail after launch.
Its clients include automotive manufacturers and suppliers, medical-device makers, finance organisations, electronics companies and industrial businesses. Some are public - JLR says it has worked with Codethink for more than a decade - while many stay hidden behind confidentiality. The work is business-to-business, usually sold as specialist teams, technical consulting and long-running engineering engagements. Supplied company data puts annual revenue around $26 million, though Codethink does not publish that figure itself.
This sounds like a consultancy until the conversation reaches trust. Since 2016, Codethink has pursued a stubborn question: can mature open-source software, including Linux, be used in systems where failure might harm somebody? The answer it has built is neither a cheerful yes nor a proprietary wrapper. It is an argument made of evidence.
Sometimes the cleverest team is one engineer
A revealing Codethink case study begins with a client asking for a development team to build a phone-synchronisation service for an online-gaming product. The expected schedule was six to nine months. Codethink looked for an existing open-source component, produced a demonstration within hours and assigned one engineer to configure and integrate it. The company says the work took 30 days of effort and cost more than 90 percent less than the client's budget.
That is an odd sales story for a business that bills for engineers. It also explains the pitch. Codethink is not trying to be the cheapest source of general-purpose developers. It is paid to recognise when a problem is already solved, find the seam where a mature component should fit and leave the client with something maintainable. The product is judgement at the systems layer.
Another engagement had less comic timing. A platform supplier proposed a trusted-boot change that would increase storage requirements for every device variant and complicate future updates. Left alone, the design could eventually fill devices and disrupt the production line. Codethink designed, implemented and tested an alternative with A/B update support in four weeks. Here the first failure was not code. It was architecture: a security solution whose operational cost multiplied with every product variant.
The component passed. The system still failed.
In a 2026 interview, Codethink president John Ellis identified integration as the place where hidden dependencies appear. That diagnosis is the company's market position in one word. A carmaker can buy silicon, an operating system, middleware and applications from accomplished vendors; none owns the behaviour of the assembled whole. A medical-device company can review firmware and still struggle to reproduce the exact binary shipped six years earlier. A finance team can add compute and remain blocked by a build graph that no one understands.
Codethink's tools grew out of those frictions. BuildGrid distributes build requests across worker machines using the Remote Execution API. BuildStream models how software components are assembled. Testing in a Box connects continuous-integration pipelines to real hardware. Supply-chain mirrors preserve source and licence history. Its Software Integration Factory packages the larger idea: standard machinery for producing and maintaining high-integrity software stacks.
The distinction from a large transformation consultancy is depth and independence. Codethink contributes upstream, works across C++, Rust, Python, Linux and bare-metal environments, and is comfortable telling a client the requested fix is the wrong fix. Against embedded vendors such as Wind River, Elektrobit or Red Hat, it is less committed to selling a single proprietary platform. Against an internal team, it offers concentrated experience from many integration failures. The disadvantage is equally clear: specialists still need a client with technical ownership, access to suppliers and the will to change a process.
“We'll often tell customers how they're doing it wrong, but we'll do what they need rather than what they think they need.”Laurence Urhegyi, Codethink
A safety certificate is a photograph. Software is a film.
Codethink's safety journey began when Bosch asked whether open source could be used in a safety-critical context. The company initially found a commercial mismatch: open-source development happens in public while conventional safety programmes are wrapped in contracts, private evidence and fixed releases. That answer changed when the team reframed the problem. Rather than ask whether Linux was intrinsically safe, ask what promises a particular system makes, what might violate them, what mitigations exist and what evidence supports confidence after each change.
The Trustable Software Framework expresses that discipline through six tenets: Provenance, Construction, Changes, Expectations, Results and Confidence. A team should know where every input came from, be able to reproduce the output, understand modifications, state expected behaviour, collect test results and make an explicit confidence judgement. The framework is now an Eclipse Foundation project, contributed and maintained by Codethink rather than kept as a consulting secret.
The approach accumulated checkpoints. In 2019, research with MIT produced AV-STPA, an open project for analysing autonomous-vehicle safety requirements. In 2021, assessor exida qualified a Deterministic Construction Service reference implementation for automotive software up to ASIL D. In May 2025, exida published a baseline assessment supporting Codethink's safety argument for CTRL OS up to SIL 3 / ASIL D. That October, it completed a positive functional-safety assessment of the framework against IEC 61508, aligned with ISO 26262.
The important noun is baseline. CTRL OS does not sprinkle certification over any product that boots it. A deployed vehicle or machine still has particular hardware, configurations, hazards, assumptions and integration evidence. Codethink's offer is a defensible starting point and a method for keeping the argument current while software changes. That matters in automotive, where update obligations can stretch for years after the last model leaves the factory.
“You can't audit your way to trust. You have to build it.”Codethink
The test now sits inside a vehicle programme
In 2025 Codethink became a Strategic Member of the Eclipse Foundation and its Software-Defined Vehicle Working Group. In April 2026 it joined JLR and Arm in ASTech, part of the UK Government-backed DRIVE35 programme. The project puts Arm's automotive compute platform beneath JLR's next-generation electric-vehicle architecture, with CTRL OS and Codethink's Software Integration Factory underneath the integration work.
This is the shift from a consultancy's method to shared infrastructure. Codethink can still sell architecture reviews, kernel work, build acceleration and lifecycle support. But CTRL OS and the factory turn repeated lessons into assets. The Eclipse framework creates a neutral language that OEMs, suppliers, assessors and regulators can inspect. That openness is not charity around the edges of the business; it is a distribution strategy for the method and a source of credibility for the services around it.
Who benefits? Teams assembling a long-lived product from many suppliers; organisations that cannot recreate old releases; developers drowning in manual compliance evidence; and managers whose expensive test hardware waits for a seven-gigabyte image to cross a continent. Codethink says one automotive delivery redesign used delta transfers and automation to support a 16-hour follow-the-sun loop, increasing test capacity for teams totalling up to 35 full-time equivalents. The transferable lesson is wonderfully unglamorous: measure the wait, automate the hand-off and send only what changed.
Mirror external source, pin provenance, make builds repeatable, state system promises, automate tests and store evidence beside each change.
Technical ownership, supplier access, stable safety goals, disciplined change control and leadership willing to expose uncomfortable evidence.
Integration knowledge stays in people's heads, evidence is gathered after release, or a supposedly reproducible build depends on a vanishing service.
A short-lived low-risk product may not justify the overhead; a locked proprietary stack may block the transparency the method depends on.
Codethink's culture follows the same logic. The company says all work should be documented and independently reviewable. Employees share knowledge through peer-led classes and receive up to £2,500 a year for training and conferences. Staff are called “Codethings,” a name just goofy enough to keep the process manual from swallowing the humans. There is also a reputation for strong opinions. In systems work, politeness is useful; pretending the dependency graph is fine is not.
The company fits in a narrow but expanding gap. Software-defined vehicles, connected medical products and industrial machines want the component abundance and update speed of open source. Safety, security and liability demand evidence, reproducibility and long maintenance. Codethink sells the bridge between those demands. Its thesis is not that open code deserves trust. It is that trust should be a decision someone can inspect - and revise when the code changes.