Most projects reach me as a message of a few lines. Something needs building, or something already built needs to change, and the question at the end is almost always the same: how much will it cost?
An honest answer needs a description of the work precise enough to price, and a message of a few lines is not that yet. Anyone who puts a number on it at that point is guessing, and a guess tends to turn into a promise nobody can keep.
This article is about how we get from the message to a price I can stand behind: what happens in the first conversation, how to prepare for it, what the written scope contains, how the first step is chosen, and when a paid review has to come first. At the end there are a few questions worth asking about any quote, from me or from anyone else.
The first conversation
The first conversation costs nothing and is not a sales call. I do most of the listening, and I am trying to understand five things:
- What you want to build or improve, in your own words. Not yet the solution you have in mind, but the problem it solves and for whom.
- Who uses it, and what they do with it. A screen used by three people in a warehouse and a page used by ten thousand shoppers are different projects even if they show the same data.
- What already exists: software, data, suppliers, contracts, and who knows how each of them works.
- What must not break while the work is done. Orders that must keep coming in, invoices that must keep their numbering, a mobile app already in people’s phones.
- Whether there is a date that really matters, and what happens if it is missed. A trade fair is a real date; "as soon as possible" is not.
By the end of it I should be able to tell you whether this is work I do well. If it is not, I say so then, not after a proposal.
How to prepare for it
You do not need a specification. What helps most is whatever shows the real situation:
- screenshots of the screens people use today, especially the annoying ones
- the spreadsheet that fills the gap the current system leaves
- a real example of the thing that goes wrong: the e-mail a customer sends, the invoice that had to be corrected
- a rough idea of volume: orders a day, users, records, files
- access details you are allowed to share, if an existing system is involved
A five-minute look at a real screen tells me more than half an hour of description, and it keeps both of us talking about the same thing.
What a written scope contains
After the conversation, you get a written scope for a first step. It is short, and it contains:
- the goal of the step, in one or two sentences
- what is included, as a list of things a user will be able to do
- what is explicitly left out, so nobody discovers the gap at the end
- what I need from you, and by when: content, access, decisions
- how we will both know it is finished: what you will be able to click on and check
- the known unknowns: the things neither of us knows yet, and what happens if one of them turns out badly
- the price for this step
The list of what is left out is often the most useful part. Most arguments about software projects are about something one side assumed was included and the other never thought of.
For a shop that retypes every order into its courier’s website, the scope for a first step might read roughly like this:
Goal
Create courier labels from the order, instead of retyping them.
Included
- A "create label" action on the order screen
- Delivery type, address or office, and cash-on-delivery amount
read from the order
- Tracking number stored on the order
Not included
- Automatic labels without a person pressing the button
- Returns and exchanges
- A second courier
We need from you
- Test and live API access from the courier, by <date>
- Ten real orders we may use for testing
Done when
- A label for each delivery type is created from a real order
and accepted by the courier
Known unknowns
- How the courier handles orders with no phone number
Price
- <the price for this step>It is deliberately plain. Anyone in the business should be able to read it and say whether it describes what they want.
How the first step is chosen
The first step is chosen to be small enough to describe precisely and useful on its own, even if nothing follows it. Three typical shapes:
- A new application: the one workflow a real user touches first, working end to end, rather than all the screens half-built. A booking system starts with a customer booking and the business seeing the booking, not with the reporting.
- A shop moving to a new platform: the catalogue and checkout on the new system, with the old orders and customers carried over, before the extras.
- An integration: one direction, one document type, running on real orders, before the edge cases.
A step like that turns assumptions into facts. After it, the next step can be priced from what we learned, rather than from what we guessed at the beginning.
When a paid review comes first
Sometimes a conversation is not enough to write a scope. The usual reason is an existing system nobody has documented: the developer has moved on, the code is not where anyone thought, or nobody knows how a change reaches the live site. Pricing work on a system like that is guessing, however confident the number looks.
Then I say so, and propose a closer look as its own paid step, with what it covers and its price agreed before it starts. It covers roughly what What I check before taking over an existing application describes: the code and how it is released, who has access to what, whether the data can be recovered, and what a safe first change would be. The result is a written list of what I found, and a scope for the work you actually asked for.
Budget, and what moves a price
If you have a budget in mind, it helps to say so early. It is not a trick to fill it. The same goal can usually be reached in more than one way, and the budget changes which first step makes sense: a lean version that proves the idea, or a fuller one that is ready for everyone on day one.
What moves a price most is rarely the number of screens. It is the unknowns:
- an old system that has to keep running alongside the new one
- data that has to be cleaned before it can move
- an outside service, a courier, a payment provider, an accounting package, whose behaviour nobody has tested
- decisions that have not been made yet, and people who have to agree on them
That is why the known unknowns are written into the scope, next to the price they affect.
How to judge any quote
Whoever you end up working with, these questions tell you a lot about a quote:
- Does it say what is not included? A quote without exclusions has them anyway; you just find them later.
- Can you tell from it what you will be able to do when the work is finished?
- Does it name the unknowns, or pretend there are none?
- Does it depend on things from you, and does it say which and by when?
- Would the person who wrote it be the person who does the work?
A quote that answers all five is worth more than a cheaper one that answers none.
Tell me what you want to build or improve.
A few lines are enough to start.