Not every problemis a web page.
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, and equally the work that is not a business system at all: 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.
The tool the business runs on
The internal application your people open every morning: the records, the states they move through, who may change what, and the report somebody currently rebuilds by hand each month. Built around the process as it is actually done rather than around a database diagram. Desktop or browser, whichever is genuinely right — and where the browser is the wrong container we say so instead of pushing one at you.
The system that outgrew the spreadsheet
It worked until it needed to be open in two places at once, until a formula broke silently, until nobody could say which copy was current. Same rules and same figures, now with accounts, history, and a version that cannot be overwritten by accident — plus the connections to whatever else you already run, so an order in one place stops being retyped into another.
Work that has to be fast
Computation that takes hours on a processor and minutes on the graphics hardware already sitting in the machine. Written against the device rather than against a framework’s idea of it: memory traffic planned, work sized to the hardware, and the timing measured rather than assumed. Performance is an engineering result, not a setting somebody forgot to turn on.
Work that has to be correct
Software that computes rather than records — simulation, modelling, analysis, anything where the output is a number somebody will act on. The part that matters is never the picture on top: it is knowing where the method loses accuracy, checking the fast implementation against a slow one known to be right, and being able to say why the answer is the answer.
Problems with no obvious answer
Scheduling, routing, layout, allocation, planning against constraints — where the good answer cannot be found by trying everything and the obvious approach quietly returns a bad one. These are solved fields with real literature behind them, and the difference between a tool and a demonstration is whether the awkward cases were handled or merely considered unlikely.
Close to the machine
Systems-level software where a runtime and a garbage collector are the problem rather than the convenience: command-line tools, long-running services, processes and pipes and memory handled deliberately. The same ground covers hardware that streams — a sensor, an instrument, a device on a port — read, decoded, and put in front of a person while it is still true.
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 ]
Analysis
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 of it is yours whether or not we build anything, including the finding that you should not.
- [ 02 ]
Specification, and the method
A written scope: what it does, what it deliberately does not, what happens when each thing fails, and what has to be true for it to be finished — which on this kind of work includes the approach itself, named and argued for, because the choice of method is a decision with consequences rather than an implementation detail. The figure comes from this document, and it comes after it. Anything added later is quoted against it rather than absorbed quietly.
- [ 03 ]
Staged build, checked against something known
Delivered in stages you can open and use, in the order that puts the painful part in your hands first. Where the work has a correct answer, it is checked against something already known to be right, on the awkward cases rather than the convenient ones. You are never asked to approve a description of something you have not seen running, and you are never six weeks from the next thing to look at.
- [ 04 ]
Handover, then keeping
The source, the deployment, the credentials and a written map of what runs where — handed over on delivery rather than held as leverage. Then it is kept: the same retainer that keeps a site keeps this, because software nobody updates is software that stops.
True of every build
A specification before a figure
We will not quote a number for work neither of us has described yet. A quote given before analysis is either padded against the unknown or about to become a change request, and both of those are paid for by you.
The code is yours
Source, repository, deployment and data. No component of it is licensed back to you, and nothing is architected so that leaving costs more than staying. If you take it elsewhere in year three, it goes.
Your data comes out
Exportable in a format something else can read, from day one, without asking us. A system that can only be left by hand is a system you are locked into whatever the contract says.
Written down, not remembered
How it works, how it is deployed, what it depends on and what to do when a job fails — in the repository, not in somebody’s head. This is the difference between software you own and software you are renting a person for.
Chosen so year two is not a rewrite
Boring, well-supported foundations over whatever is current, and the seams put where the business is most likely to change. Most rewrites are not caused by growth; they are caused by a shortcut taken in month two.
Kept by the same hands
The people who built it are the people who answer when it misbehaves. Nothing is handed to a support desk that has never read it, and there is no separate team to explain it to at your expense.
Questions
Why is there no price on this page?
Because every other page here publishes a figure we can stand behind before we have met you, and this is the one where we cannot. 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 a problem has a correct answer, the fast implementation is checked against a slower one that is obviously correct, on inputs chosen to include the degenerate cases rather than the tidy ones. 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, because a project where nothing is usable for three months is a project where nobody finds out it is wrong until month three.
We already have something and it half works. Start again?
Usually not entirely. We read what is there first, because a system in production encodes years of decisions that nobody wrote down and throwing it away throws those away too. Sometimes the answer is a rewrite, often it is a rescue — tests around the parts that matter, the worst seam replaced, the documentation that never existed. We will tell you which, with reasons, before you spend anything on building.
Who keeps it running afterwards?
We do, on the same published retainers as everything else, with the same response windows. Software that is never updated does not stay still — its dependencies age, its certificates lapse, and the failure arrives on a day you needed it. If you would rather keep it in-house, the written handover is built for exactly that, and we will hand it to your people properly rather than resent it.
Start with the process that costs you a day a week.
No sales pressure and no generic proposal. Tell us what you are trying to build and you will get a straight technical read on it and a clear next step.