Custom software development. Fixed fee, closed scope, sources yours.
Some needs do not fit a product you can buy. We build those, on a written scope with acceptance criteria, and we carry the overrun risk. When a product on the market does fit, we tell you instead of building. No vendor lock-in: you own the source, and the handover is written into the engagement rather than promised at the end.
Most companies asking for custom software should buy instead
Before anything else, look hard at what the market already sells. Not a five-minute look: list your processes, trial two or three products, and let the people who will actually use them do the clicking. If a product covers most of it and the remainder can be configured or worked around without pain, buy it. The vendor maintains it, patches the security holes and absorbs regulatory change, and you pay for configuration rather than construction.
Building earns its cost when the need genuinely falls outside the market: a vocabulary specific to your trade, integrations with systems only you run, sovereignty constraints, or a process that is itself part of your competitive advantage. Not when it simply feels better to own something made for you, which is a comfortable and expensive reason.
The first question on any project here is therefore whether it should be built at all. When the answer is no, we say so, and that conversation costs you nothing.
Four stages. Each one has a deliverable.
No stage is a status meeting. Scoping produces a scope, the build produces working software, acceptance produces a yes or a no against written criteria, and handover produces everything you need to run it without us.
- 01
Scoping, paid and short
We open the hood before quoting: your real data, the actual integration points, the edge cases that will hurt. It produces a scope both sides read the same way, and a price we can hold because it rests on what we saw rather than what we guessed. The document is yours even if you take it elsewhere.
A quote that rests on evidence
- 02
Build on a closed scope
Fixed fee, written acceptance criteria, short cycles with working software you can try. What is in scope is owed. What is not becomes a priced change order, decided knowingly rather than absorbed silently.
Overrun risk on our side
- 03
Acceptance on the edge cases
We test the paths that break, not only the demo path: a cancellation after payment, a corrupted import, two people editing the same record, a connection dropping mid-write. Real data volumes, not three clean rows.
Tested before go-live, not after
- 04
Handover, then we step back
Source code, documentation written as we went, a decision log explaining the reasoning, credentials transferred, and one person on your side trained to run it. Optional light monitoring afterwards if you want a quiet first year.
You own all of it
It is rarely the estimate. It is the scope nobody wrote.
Projects that go wrong seldom go wrong because the initial quote was too low. They go wrong because five things were never pinned down, and each of them arrives as a change order.
- A scope left implicit. Every meeting adds a feature that seemed obvious. End to end, those obvious things double the budget. A single line saying « and stock management too » can hide three weeks of work.
- Data migration assumed simple. Everyone expects an export and an import. Then half the records turn out to have empty fields, mixed formats and duplicates, and cleaning becomes a project inside the project.
- An integration discovered halfway. « It also needs to post into our accounting system. » Said at mid-point, that sentence is expensive, because the architecture was never designed for it. Planned from the start, the same integration costs a fraction.
- Load requirements never stated. Software that works for a hundred users can fall over at ten thousand. If nobody said it had to hold, it was not built to, and you find out on the day success arrives, which is the worst possible moment.
- Maintenance budgeted at zero. Software is not a delivery you set down and forget. Browsers move, connected services change their rules, security patches ship. Planning nothing for the year after go-live guarantees an unpleasant surprise.
A closed scope with written acceptance criteria is what turns all five from silent drift into explicit decisions. That is the whole point of the fixed fee: if the estimate was wrong, it is our margin that absorbs it, not your budget.
Four questions worth asking any vendor.
-
When is custom software the wrong answer?
Whenever a product on the market covers most of the need and the rest can be configured or worked around without pain. Then buy it: the vendor maintains it, patches it and absorbs regulatory change, and you pay for configuration rather than construction. Custom development earns its cost when the need genuinely falls outside the market: a vocabulary specific to your trade, integrations with internal systems, sovereignty constraints, or a process that is itself a competitive advantage. Not when it merely feels nicer to have something made for you.
-
What makes a custom software budget overrun?
Five things, and only the first is obvious. A scope nobody wrote down, so every meeting adds an obvious feature. Data migration assumed to be an export and an import, when the records are inconsistent and duplicated. An integration discovered halfway, which costs several times what it would have cost if designed in from the start. Load requirements nobody mentioned, surfacing on the day success arrives. And maintenance budgeted at zero, which turns into an unpleasant surprise within months.
-
Who owns the code and the documentation?
You do, and it is written into the contract before anything starts. Sources, documentation, credentials and accounts transfer at delivery without restriction on use. That single clause removes the most common trap in this market, the vendor whose knowledge lives only in their own head. If a supplier hesitates on that point, you have learned something important.
-
Can the work be delivered in stages to spread the budget?
Yes, and it is often the better approach. We ship a foundation that is useful on its own, then add capability in waves, each priced separately. You spread the spend, you validate the value at every step, and you keep the option to stop or change direction. The one condition is that the initial architecture is designed to receive what comes next, which is a decision made at scoping and not later.
Describe the need. We will say whether to build it.
Twenty minutes is usually enough to tell whether this calls for custom software, a product off the shelf, or nothing at all for now.