Livesport
Nine internal systems for one of the world’s most-visited sports-results platforms, used by more than 100 million people. We built them and we still run them, years on.
Read moreProduct engineering
Building the software, once the evidence says it is worth building
Once a better method has been proved, it has to become software that people rely on every day, and that is a different job from proving it. We build the product the evidence supports, no more and no less, and we build it to be operated for years. Demonstrating it once in a meeting is a different craft. But this is the largest of the three steps, so the two in front of it exist to tell you whether it is worth buying: an audit from €15,000 that says whether the decision carries enough money to be worth a system, and a proof of value from €40,000 that says whether the better method beats the way you decide today. The senior people who framed the problem stay on it through to production, because that is when the framing gets tested.
What we build
The kinds of work we take on
The work worth giving us is the kind where being wrong costs something, and where four experienced people are cheaper than twelve inexperienced ones. That is most consequential software and very little of the other kind. And the list below is roughly the list every development shop prints. What differs is how much of it gets built: the audit and the proof have usually cut the original wish by the time we quote, and the smaller build is the one we would rather sell you.
-
New products
Build a product from a validated idea, architecture, data, interfaces and operations included, where a demo cannot be taken into production.
-
Internal decision systems
Turn a proven method into a system your teams use daily: wired to your data, embedded in the workflow, monitored and answerable to a person.
-
Modernisation of consequential software
Rework the systems a business runs on, where correctness and continuity matter more than a rewrite for its own sake.
-
Co-development with your team
Work alongside your engineers, raising the standard of the code and the decisions behind it, and leaving capability in the building when we go.
-
Architecture and data systems
Design the data foundations and system structure a decision system needs before it can be trusted in production.
-
AI and model integration
Integrate learned models where a concrete mechanism justifies them, with measurement and guardrails around whatever remains uncertain.
-
Reliability, observability and security
Treat operating properties as first-class: instrumentation, failure modes, recovery and security are designed in from the start.
-
Formal verification where justified
Where a failure is too expensive to leave to testing, prove the critical logic. We apply formal methods only where the risk earns the cost.
See Rainbow ↝
Proof
Systems we built that are still running
A row of logos tells you who once paid an invoice. A system still in production years later tells you more. These three are ours, and we still carry the consequences of them.
Gitrevio
A multi-tenant decision-science platform we build and run ourselves, connecting planning, delivery and business outcomes. 31 connectors and 388 agent-callable decision-science functions in production, counted in the code in August 2026.
Read moreHow it is bought
How a build starts, and what it costs to find out
Three steps, each with its own price and its own decision gate. You commit to the next one only once the last one has earned it, and two of the three are cheap enough to stop at.
One · from €15,000
An audit that sizes the decision
Two to three weeks with a partner, ending in a number and one of three words: go, reshape or stop. The number is what one of your repeated decisions costs on your own figures. And when it comes back saying that no system is warranted, that is the cheapest thing you will buy all year.
The audit ↝Two · from €40,000
A proof on your own data
Four to eight weeks running a candidate method against an agreed baseline, with the mess left in the data and a named sponsor on your side. It answers whether the method beats what you do today and by how much. It is allowed to answer no, and it has.
How we validate ↝Three · quoted from the proof
The build itself
A small senior team that carries the system into production and, where you want it, keeps running it. We publish no rate card for this, because the honest number depends on the system and the proof has just produced the scope it needs. It is agreed in writing before anything starts.
When we are a fit
- Being wrong costs money, and somebody in the building can say roughly how much.
- The system will be operated for years by people you can name.
- A senior person is accountable for the decision the software makes.
When we are not
- The scope is already fixed and not open to argument. We will argue with it, and that is the part you would be paying for.
- What is wanted is a demonstration for a meeting, with nobody set to operate it afterwards.
- A spreadsheet, an off-the-shelf tool or a simpler mechanism would do the job. Then that is the answer, and finding it is part of what the audit is for.
Who is accountable
One engagement partner is answerable for the whole relationship, including the parts that go badly, and is who you call when something is wrong. The same person runs the audit, signs the recommendation and stays on the build. So the estimate and the delivery belong to one name. The ladder above is the Find, Prove, Build sequence the rest of the company runs on, and what we require as evidence before a system is trusted is set out in how we validate.
Working model
Who does the work
A small, senior team carries the problem from framing through to a system in operation. Nobody is handed anything by somebody who is no longer on the project.
- The people who frame the problem stay on it, so context is not lost in handover.
- Depth is added only where the problem needs it: a decision scientist, a data engineer, a formal-methods specialist when the risk justifies one.
- We work alongside your engineers and never around them, so that when we leave, the capability stays.
The technology
Tools are chosen to fit the problem. In practice much of our work sits on data-oriented systems in Clojure and Python, with formal verification in Rainbow where a proof is warranted. The stack is a means. We have opinions about it, but they come after the problem.
Clojure Python Data-oriented systems Formal methods
And if a different technology is the right answer for your system, that is the one we will recommend. We have done so before. The organising principle is the decision and its consequences.
FAQ
Questions about product engineering
What does a build cost?
We do not publish a figure for one, and a number invented before we have seen your system would be worth nothing to either of us. The two steps in front of it are priced on this site: an audit from €15,000 and a proof of value from €40,000. By the time the proof is finished the build has a scope and a number that came out of your own data. There is no rate card behind it, and it is agreed in writing before anything starts. If the audit sends you on to the proof, the audit fee is credited against it, so you do not pay twice for knowing.
Can we skip the audit and the proof?
Yes, if you arrive with the proof already done. Some companies have run the analysis themselves, or have lived with the problem long enough that the economics are not in question, and in that case we start at the build and say so. What we will not do is skip the arithmetic altogether. If nobody can say what the decision costs today, the build has no size, and we would be guessing at your expense.
How is this different from a generic development shop?
A development shop is paid for the build, and the build is scoped by whoever wanted it. We build only what the evidence from the audit and the proof supports, and that is usually smaller than the original wish, and we build it to be operated in production for years and not demonstrated once. The senior people who framed the problem stay on it through to production. In ten years we have not found a way to hand a problem down a chain from sales to delivery without losing most of what mattered about it, so we stopped trying.
What kinds of product engineering do you take on?
New products from a validated idea, internal decision systems, modernisation of consequential software, co-development alongside your engineers, architecture and data systems, AI and model integration, and reliability, observability and security. Formal verification is added where a failure is too expensive to leave to testing.
Do you run systems in production, or only build them?
We run them. For Livesport we built and still operate nine internal systems for one of the world’s most-visited sports-results platforms, used by more than 100 million people. Gitrevio is a decision-science platform we build and run, with 31 connectors and 388 agent-callable decision-science functions in production.
What does production hardening include?
Treating operating properties as first-class: instrumentation, failure modes, recovery and security designed in from the start, along with the data foundations and system structure a system needs before it can be trusted in production.
Which technologies do you use?
Much of our work sits on data-oriented systems in Clojure and Python, with formal verification in Rainbow where a proof is warranted. The stack is chosen to fit the problem. If a different technology is the right answer for your system, that is the one we will recommend.
Do you add AI to every build?
No. We integrate learned models only where a concrete mechanism justifies them, with measurement and guardrails around whatever remains uncertain. We do not add AI where a simpler mechanism is better.
Start with the decision
Bring us the system
A new product, an internal decision system, or critical software that has to be modernised without breaking. The first conversation is about what it takes, in weeks and in money, and a partner has that conversation.