Why we will not give you a number on the first call

Search for what custom software costs and you get ranges: $20,000 to $75,000 for an MVP, $75,000 to $200,000 for something mid-sized, $250,000 and up for anything with the word enterprise attached. Every agency publishes a version of this page, including agencies whose actual projects land nowhere near their own published range.

The ranges are not dishonest. They are just useless, and it is worth being precise about why, because the reason is the same reason we will not give you a number on a first call.

Two quotes for the same brief are not two prices for the same thing

You send the same three paragraphs to four firms. One comes back with $40,000, one with $120,000, one asks for a paid discovery phase, one does not reply. The instinct is to read that as a price spread. It is not. It is four different readings of what you wrote.

The $40,000 quote is for the screens you described. The $120,000 one includes the migration of eleven years of inconsistent historical data, an integration with the accounting system you mentioned in passing, an environment somebody has to run, and the six weeks after launch when people find the things nobody thought of.

Both firms are quoting honestly. Only one of them read the sentence about the accounting system and understood that it was the project.

The variable is never a rate card. It is the boundary of the word done.

What actually moves the number

In our experience the spread between a cheap version and an expensive version of the same project comes from four things, and none of them is visible in a brief:

What has to keep running. Replacing something nobody uses yet is a different job from replacing something forty people use every day, while they use it. The second one needs both systems live at once, a period where they must agree, and a decision about which is authoritative while they disagree. That is not a feature. It is most of the schedule.

The state of the data you already have. Years of manual entry means the same client, vehicle or product written several ways. Someone has to decide which spellings are the same thing, and some of those decisions need a person who knows the business. This work is invisible in a brief and routinely larger than the interface.

What you do not control. Every integration with a system you cannot change adds a party who is not in the room. If it has no API, no test environment and no support channel, the estimate includes discovery that has not happened yet — and honest estimation of undiscovered work is a contradiction.

Who signs off. One decision-maker who answers within a day is a different project from a committee that meets fortnightly. The work does not change; the calendar doubles.

A number produced before those four are known is not an estimate. It is a bid on how the conversation will go.

The two failure modes of quoting early

Quote low and it becomes a negotiation you lose slowly. Everything not in the low number becomes a change request, and by the third one the relationship is adversarial. Nobody set out to be adversarial. The number did that.

Quote high to cover the unknowns and you have charged for risk that may not exist. If the unknowns turn out fine, you overpaid, and there is no mechanism that gives the difference back.

The industry answer to this is a paid discovery phase, which is not wrong but has an obvious flaw: you pay for a document, and the document’s usefulness is entirely dependent on the firm that wrote it also doing the build.

What we do instead

A written scope, and it is yours. After enough questions to answer the four things above — in writing, not on a call — you get a document saying what gets built, what deliberately does not, and what it costs. If you take it to another firm and have them build it, that is a legitimate outcome. We would rather write a scope that can survive being shopped around than one that only makes sense if we hold it.

Questions in writing before any call. Partly because it is faster, mostly because written answers are answers you have thought about. A discovery call is largely a performance of diligence; the same questions in email get better information, and there is a record of what was agreed.

Or an honest no. We turn down projects that need a specification handed over and checked back on in six months, staffing by the seat, and anything where the real problem is organisational and software is being asked to fix it. Saying so at the scope stage is cheaper for everybody than discovering it in month four.

The part buyers ask about second

Price is the first question. The second is some version of “what happens if this goes wrong”, and it is the more reasonable of the two. Here is our answer, in the order the risk actually matters.

The code is yours from the first week, not at the end. It lives in your repository and runs in your cloud account, under your billing, with your credentials. Not a copy handed over at delivery — the actual working system, from the first slice we deploy. We cannot hold your system hostage because we are never the only ones holding it.

Every cycle ends with something running. Two-week cycles, invoiced in advance, each finishing with working software rather than a status report. That structure exists to bound your exposure: the most you can lose to a decision that turns out wrong is one cycle, and you can stop at any boundary without negotiating an exit.

A written runbook comes with it. Every cycle produces documentation of how the thing is deployed and operated, so another team can pick it up without talking to us. That is the actual test of whether you own something: not whether the licence says so, but whether somebody else could run it tomorrow.

We are a small firm, and we say so before you ask. We are a sole proprietorship, not a corporation with a legal department, and the commercial terms — invoicing arrangements, schedule, what happens if either side wants to stop — get agreed in writing before any work starts, not assumed from a template. We do not publish a payment mechanism on this page because the honest version depends on where you are and what your finance team can process, and a promise made on a marketing page is the wrong place to find out it does not apply to you.

What we do not offer: a fixed price for a project nobody has scoped, an SLA we have no capacity to honour, or a guarantee that the estimate cannot move. What we offer instead is that it moves in daylight, with a written reason, at a boundary where stopping is cheap.

What to ask any firm, including us

Four questions that are hard to answer smoothly if the answer is bad:

1. What is in your number that a cheaper quote would leave out? A firm that has genuinely thought about scope answers this immediately and specifically.
2. Where does the code live during the project? “Our repository, handed over at the end” and “your repository from week one” are different commercial relationships.
3. What would make this take twice as long? If the answer is “nothing”, they have not looked.
4. What would you refuse to do? A firm that will do anything has no opinion, and you are buying an opinion as much as the hours.

If you have a project and want the written-scope version of this rather than a range, send us the brief. You get a reply from one of us within 1 business day, questions in writing, and then a scope with a price — or a straight no.