what an estimate actually is

an estimate is not a guess. it is a number that comes from reading what needs to be built, identifying what is unknown, and deciding what to do about the unknowns before the number is written.

the estimates that grow by 40% after the first month are the ones written before the unknowns are named. the client sees a low number, approves it, and then discovers the unknowns one by one as the build progresses. by the time the real number is visible, the project is already underway and the cost to stop is higher than the cost to continue.

how we read a brief

the brief arrives in some form — a call, a document, a deck, a voice note, sometimes a bullet list. we read it for two things: what the business is trying to achieve, and what it has told us is the solution. those two things are often different. a brief that says 'we need a mobile app' is describing a solution. what we need to understand is the outcome the app is meant to deliver — and whether an app is the right vehicle for it.

this is where the unknowns live. who uses this, what does success look like in month three, what happens if the user does not have an internet connection, how does this connect to the system that already exists. we list them, prioritise them, and decide which ones require discovery work before the estimate can be written honestly.

two options

the scoping note always has two pricing options. option a is the complete version — all the features that directly serve the outcome, with the architecture that lets the business extend it later. option b is the minimum version — the shortest path to the core outcome, without the extensibility layer.

we are transparent about what is in each version and what is not. the client picks option b when timeline or budget is the constraint. they pick option a when they know they will want to extend it. either way, the number on the note is the number we build to.

what happens after

the scoping note is the client's to keep, regardless of whether they hire us. it is a two-to-three page document with the problem in their own words, a proposed approach, deliverables, two pricing options, and a timeline. if they take it to a different shop, they arrive with a clear brief.

if they hire us, the note becomes the project agreement. we do not write separate contracts with large scope definitions that nobody reads. the note is the scope. the build is accountable to it.