Company
We build the record layer for regulated work.
Dinmore Software works with organisations whose engineers operate in hospitals, treatment works, remote sites and high-risk buildings — where the record is the only thing that proves the work happened.
This isn't our first difficult software problem
Dinmore Software may be a new name, but building software to solve difficult commercial problems is something we have been doing for decades. Some of those projects succeeded where much larger organisations had already tried and failed.
Tariff Auditor — built, commercialised and acquired
In 1998, we began developing Tariff Auditor, a software platform that analysed telecoms billing and identified the most appropriate tariffs for carriers and their customers.
The platform was the culmination of three years of development and was sold to more than 30 telecommunications companies.
We subsequently sold the technology to Lucent Technologies.
It was an early example of the approach we still use today: understand a complicated business problem, break it down, and build software that makes the process considerably simpler.
Sky CMS — solving a problem others couldn't
In 2001, we took on a very different challenge: integrating directly with Sky's CMS card management platform.
Access to the platform was highly restricted. At the time, only two other operators had successfully established this capability. We developed our own integration in around ten months and went on to replace BT for a number of services.
Our platform managed the processes behind multiple television channels, including customer registration, viewing-card management, subscription control, payment processing, reconciliation and reporting.
Several considerably larger organisations attempted to enter the same market. They committed substantial development teams and significant investment to the problem, but were unable to make their integrations work successfully. During the 14 years we operated in the market, no other new competitor managed to achieve what we had built.
We also changed the operating model. Rather than relying on expensive traditional 'green-screen' infrastructure, we ran the operation from a 150-seat centre in Mauritius using IP-based technology. That dramatically reduced the cost base and enabled the operation to be profitable from its first month.
The technology was important, but the real achievement was understanding a complex system well enough to find a practical way through it. That remains central to how we develop software today.
How we work
Evidence over dashboards
A pretty chart nobody can trace back to a signed record is decoration. We optimise for defensibility first.
The engineer decides adoption
If the person in the plant room won't use it, nothing else matters. Every design decision is tested against a gloved thumb on a wet screen.
Boring where it counts
Data portability, open exports, versioned templates. The unglamorous parts are the ones you'll thank us for in year four.
Why we started with BMET
Biomedical engineering is the hardest version of the problem. Thousands of assets, dozens of device classes, tolerance-driven results, safety notices, and consequences that reach a patient. If a records platform holds up there, it holds up anywhere.
Clinical research operations followed naturally: the same sites, the same equipment, the same inspectors — and an even sharper standard of documentation. From there the pattern generalises to any sector where a scheduled inspection produces a legal record.
We work with organisations delivering care and risk management in demanding environments, including remote and international operations where connectivity is never guaranteed.
A faster way to build
We use modern AI-assisted development tools alongside decades of experience in operational software and planning.
They don't replace the thinking. We still have to understand the problem, design the process, test the logic and prove that it works.
What they can do is significantly reduce the time between understanding a problem and putting a working solution in front of the client.
On one recent Axiom project, a servlet estimated elsewhere at around ten development days was built into a working solution in four.
That won't be true of every project, but it demonstrates what the approach can achieve when the problem is well understood.
Talk to the people who build it
No SDR script. You'll speak to someone who has configured Apex for a live estate.