Pricing
What custom software costs, and what actually moves the number
We do not publish a day rate, because a rate answers a question nobody is really asking. What decides your cost is scope, how much is unknown, and how much of the work is integration with things we do not control. Here is how we price against that, honestly.
- WrittenScope before a number
- YoursCode, infra and accounts
- No lock-inLeaving stays cheap
The variables
Six things that move a quote more than the hourly rate does
If two estimates for the same brief differ by triple, the difference is almost always in this list rather than in the rate card.
How much is genuinely unknown
A well-understood CRUD application is estimable. A product still deciding what it is has to be paid for in short, reversible pieces — anything else is a fiction with a decimal point.
Integrations you do not control
The single biggest source of overrun. An undocumented legacy API or a vendor with a two-week support turnaround costs more than the feature attached to it.
Compliance and data residency
GDPR, ENS, sector rules and audit trails are architecture, not paperwork added at the end. Cheap to design in, expensive to retrofit.
Quality bar and blast radius
An internal tool that ten people use and a payments path that cannot be wrong are different jobs. Test depth and review rigour are a dial, and it is yours to set knowingly.
Whether it is operated after launch
Most of the lifetime cost of software is after the first release. An estimate that stops at launch is not an estimate of the software.
Who is available on your side
The cheapest projects have one decision-maker who answers within a day. Waiting on decisions is billable time in every model.
Engagement models
Three ways to buy, and when each one is the honest choice
Fixed price
For work whose scope is genuinely settled: a defined integration, a migration, a redesign of something that exists. You get one number and we carry the estimation risk — which we price for, so fixed price is rarely the cheapest outcome, only the most predictable one.
Time and materials
For product work, where the specification is what you are still discovering. Cheaper in expectation because nobody is pricing a risk buffer, and it requires you to actually look at the burn every sprint.
Dedicated team
A monthly cost for a known set of people who are yours. The right shape once there is more than one release ahead of you, and the one that gets cheapest per unit of work over time.
A capped first piece, whichever you pick
We would rather start with one small, useful deliverable at a fixed cost. It answers the question a proposal cannot — whether you want to work with us — before either side commits to a year.
How we quote
A number you can interrogate, or it is not worth having
Before quoting we write down what we think you are asking for, in enough detail that you can disagree with it. Most of the value is in that document rather than in the figure at the end: it is where the assumptions become visible, and where a misunderstanding costs an afternoon instead of a quarter.
The estimate that comes back names its assumptions, says which parts we are confident about and which are ranges, and identifies the things that would change it. If a number arrives without that, from us or from anyone, it is a guess wearing a suit.
We will also tell you when the answer is not to build. A configured off-the-shelf tool, a scheduled export, or a rules engine beats bespoke software more often than a development company is usually keen to say — and establishing that in week one is much cheaper for you than discovering it in month four.
Common questions
What buyers ask about cost
Why do you not publish day rates?
Because a rate is only comparable if everything around it is identical, and it never is. A lower rate with junior staffing, a distant time zone and no tests is more expensive per unit of working software, and a rate card invites exactly the comparison that hides that. Tell us the problem and you will get a number for the problem.
Roughly what does a first version cost?
It depends far more on the shape than the size, so an honest answer needs one conversation rather than a table. What we can commit to before that: a scoped first deliverable at a fixed cost, so your initial financial exposure is small and known regardless of where the whole thing lands.
Is fixed price or time and materials cheaper?
Time and materials, in expectation, on anything whose scope can still move. A fixed price has to include a buffer for estimation risk, and you pay that buffer whether or not the risk arrives.
Fixed price buys predictability rather than savings. It is the right answer when the scope genuinely is settled, or when your own approval process needs one number.
What happens when scope changes mid-project?
In time and materials it is a conversation about priority, and the trade-off is visible in the sprint. Under fixed price it is a change order, which is slower and is the real cost of that model. Either way we would rather show you the trade-off than absorb it silently and deliver something rushed.
Are there costs after launch?
Yes, and anyone who implies otherwise is deferring them rather than removing them: hosting, third-party services, dependency and security updates, and the changes real usage always asks for. We quote support and maintenance separately so you can see what running it costs before you decide to own it.
What do we own when we stop paying?
Everything: the code, the infrastructure, the accounts and the written architecture decisions, from the first commit. There is no licence retained and nothing we would have to hand over later, because it was yours all along.
Bring us the problem and we will price it
Thirty minutes with a senior engineer, and a written scope you can disagree with before there is a number attached to it.