"Roughly how much would it cost?" is a fair first question. The honest answer is that I do not know yet, and anyone who gives you a firm number at that point is either guessing or quietly pricing in a cushion for the guess. A fixed price is a promise. Before I make one, I need to know exactly what I am promising.
That comes from a short process: questions, a written scope, then a number, plus a rule for when the plan changes.
Questions before numbers
The first conversation is mostly me asking questions, and few of them are about technology, because the size of a job is decided by the business problem. Three questions do most of the work.
What is broken?
Not "what do you want built", which arrives already shaped as a solution, but what is going wrong today. A request for "an app" is often really a request to stop someone re-typing orders from email into a spreadsheet every morning. Those are different jobs, and the second may not need an app at all. If the thing you want built should not be built, this is where I say so, before it has cost you anything.
Who touches the data?
Where the information lives now, who types it in, who reads it, and who else depends on it: the accountant, a supplier's system, whoever prepares the year-end figures. Each one is a conversation, an import or an edge case, and this moves an estimate more than any technical question. My years in audit and SAP systems help here, because the awkward cases tend to sit exactly where day-to-day operations meet the ledger.
Alongside it: who on your side can say yes? A project where every decision waits for a meeting takes longer, and it is fairer to know that at the start.
What does "done" look like?
The question people find hardest, and the one a fixed price depends on most. "Done" has to be something we could both check without an argument: the month-end reports run from the new system, the old spreadsheet is retired, new staff can add a customer without asking anyone how. I also ask what happens when it goes wrong: a tool that sends invoices needs more care than one that tidies a mailing list. If we cannot describe done, the job has no edge, and it cannot be priced honestly.
Writing the scope down
Once I understand the job, it goes into a short written scope in three parts. People rarely expect the third.
- What is in. The features and outcomes, specific enough to test against: "staff can export the month's invoices in the format the accountant uses", not "reporting".
- What is out. Things that came up in conversation but are not in this price: the mobile version, the second branch, importing years of old records. Writing them down is not being difficult. It stops two people remembering the same conversation differently later.
- What I need from you. Access to the systems, sample data, someone who can answer questions within a few days, and a named person who signs off. A fixed price assumes these arrive. If they do not, the dates move, and we both know that from the start.
The price goes against that scope and only that scope. The flip side matters just as much: if part of the job turns out harder than I estimated, that is my problem. The number does not move unless the scope does.
When the scope moves
Scope always moves a little. I show working software early, on a URL you can open, so better ideas arrive sooner, while they are still cheap to act on.
The rule is simple. If the scope moves, the price moves before the work does, never after. A new request gets a short written note: what changes, what that does to the price and the date, and whether something else could come out to make room. You decide before I build any of it. Nobody gets a surprise invoice for "extras", and nobody argues about what was agreed, because it is on paper.
Often the best answer is a swap: something less important leaves to make room. Sometimes it is to finish this version and price the idea as the next piece of work. What is not fine is quietly absorbing changes until the project is late and both sides feel short-changed.
When the honest first step is small
Some jobs cannot be priced from a conversation, however careful. The data might not have been looked at properly in years. An old system might need reading before anyone can say what it does. An AI feature depends on whether a model copes with your real documents, not a tidy demonstration.
In those cases the honest first step is a small, separate piece of work: read the existing code, map how the process really runs, or try the approach on a sample of your own data. It ends with something written that you keep: what I found, what I would build, and a fixed price for building it. If it should not be built, you hear that too, after a short piece of work instead of a long one.
It can feel like a detour before the real work. The alternatives are worse: a fixed price padded to cover what nobody knows yet, or a low one that becomes a difficult conversation later. Starting small is how I avoid guessing with your money.
None of this is clever, and it is not meant to be. A fixed price works when both sides know exactly what it buys, so most of the effort before a project goes into making that plain. If you have a problem you would like priced that way, describe it on the contact page, and the first thing you get back will be questions.
