Not every problemis a web page.
Custom software beyond the web — internal tools, performance-critical and numerical work, systems that talk to hardware.
The rest of this site prices web work, where the shape is predictable enough to publish a ladder against. This page is for everything else we build — the internal tool a company runs on and has never costed, software that has to be fast enough on the hardware to be usable, or numerically correct, or able to talk to a device. There is no figure printed here because the problem decides it, and a floor published before we understand the problem is a guess with a euro sign in front of it.
What this covers
Written as the work actually arrives rather than as a menu. Some of it is ordinary business software and some of it is not; the reason both sit on one page is that the discipline underneath them is the same.
Business software
The tool the business runs on
The internal application your people open every morning: the records, who may change what, and the report somebody currently rebuilds by hand each month. Built around the process as it is actually done.
The system that outgrew the spreadsheet
It worked until it needed to be open in two places at once and a formula broke silently. Same rules, now with accounts, history, and a version that cannot be overwritten by accident.
Problems with no obvious answer
Scheduling, routing, layout, allocation. Where the good answer cannot be found by trying everything, and the obvious approach quietly returns a bad one.
Engineering-grade work
Work that has to be fast
Computation that takes hours on a processor and minutes on the graphics hardware already in the machine. Written against the device, with the timing measured rather than assumed.
Work that has to be correct
Software that computes rather than records — simulation, modelling, analysis. Knowing where the method loses accuracy, and checking the fast version against a slow one known to be right.
Close to the machine
Systems-level software where a runtime is the problem rather than the convenience — and hardware that streams: a sensor, an instrument, a device on a port.
How it runs
The order matters more here than anywhere else on this site. Every bad custom software project we have been asked to rescue was priced before it was specified.
- [ 01 ]
Paid analysis — yours whether or not we build
We sit with the work as it is done now — the actual clicks, the actual exceptions, the step everybody works around. Paid, and short. What comes out is yours whether or not we build anything.
- [ 02 ]
Specification, and the method
A written scope: what it does, what it deliberately does not, and what has to be true for it to be finished — including the approach itself, named and argued for. The figure comes from this document, and after it.
- [ 03 ]
Staged build, checked against something known
Delivered in stages you can open and use, painful part first. Where the work has a correct answer it is checked against something already known to be right.
- [ 04 ]
Handover, then keeping
Source, deployment, credentials and a written map of what runs where — handed over on delivery rather than held as leverage. Then it is kept, on the same retainers as everything else.
Questions
Why is there no price on this page?
Because the pages with a ladder publish a figure we can stand behind before we have met you, and this is not one of them — nor is AI and automation, for the same reason. Two projects described in the same sentence differ by a factor of ten depending on how many exceptions the process has and what it has to talk to. What we will do instead is put a small, fixed, paid analysis in front of it, and the number that comes out the other side is against a written specification rather than a hope.
How is this different from the web application on the ladder?
The ladder is for software whose front door is a website — a public site with accounts, content and records behind it, and the price steps are predictable because the shape is. This is for software whose front door is the work: an internal tool, a system between systems, something with no visitor at all. When your project is really the first kind, we will tell you, and you will pay the published ladder price rather than a bespoke one.
Do we own what you build?
Yes, entirely, and that includes the source, the deployment and the data. We do not license anything back to you and we do not keep a component that only we can maintain. The handover is part of delivery, not something to negotiate at the end — and the reason to keep us afterwards should be that we are good at it, not that leaving is expensive.
How do you know it is right?
By not taking the software’s word for it. Where there is no single correct answer — anything that estimates or optimises — there is only a measured error rate on data that was not used to build it, and a written statement of what happens when it is wrong. Software that has never been told what being wrong costs has been assembled rather than engineered.
How long does it take?
Analysis is usually a week or two of elapsed time. After that, the honest answer is that the specification tells us, which is precisely why it exists — but the first usable stage is deliberately early.
Start with the process that costs you a day a week.
Tell us what the business is doing by hand that it should not be.
If what you need is an assistant grounded on your own content, that is on the AI and automation page.
AI and automation →