There is a version of this conversation that happens constantly. A company decides it needs software, describes what it wants in a paragraph, receives three quotes that differ by a factor of four, and has no way of telling which one is right. The natural conclusion is that developers are unpredictable. The actual cause is usually that the paragraph could be read four different ways, and each quote priced a different reading of it.
You cannot fix that by asking for more detailed quotes. You fix it by turning up with the five things below, none of which require any technical knowledge and all of which you already have somewhere in your head.
Why this is worth an afternoon
Software gets more expensive to change the further into a project you are. Changing a sentence in a document costs a sentence. Changing the same decision after the database has been designed around it, and eleven screens have been built on top of it, costs a week of somebody's time and a conversation about who pays for it.
Nobody argues with that in principle. The reason projects keep failing on it is that the expensive decisions do not look expensive when they are made. "Can a customer have more than one address?" is a question that takes four seconds to answer and can cost a month to answer late.
Working the following out in advance does not remove that risk. It moves most of it into the cheapest week of the project.
One — the problem, in one sentence, without the solution in it
Write down what is wrong, in a sentence that does not contain the word website, app, system or platform.
Not: we need a customer portal. But: dealers phone us to ask where their order is, and one person spends most of every morning answering.
This is harder than it sounds, and it is the single most useful thing you can bring to a first conversation. The first version names a thing to build, which closes off every alternative before anyone has looked at them. The second names a problem, and a problem can be solved several ways at several prices. Some of those ways are much cheaper than the thing you had in mind.
If you cannot write the sentence, that is genuinely useful information. It usually means either the problem is several problems wearing one coat, or that the real driver is something nobody has said out loud yet.
Two — who actually uses it, including the people nobody asks
List the people who will touch this thing, by role rather than by name. Then, next to each, write what they are trying to get done and how often.
The list almost always contains someone who was not in the original conversation. The person who processes the orders. The one who does the reconciliation on Fridays. The van driver who will have to update something on a phone in the rain. These people know how the work actually runs, as opposed to how it is supposed to run, and they are the ones who will decide whether the software gets used or quietly worked around.
A specific warning about the difference between a buyer and a user. If the person paying for the software is not the person using it every day, and they are the only one consulted, you get software that demos beautifully and is resented within a month. Getting an hour with two actual users before anyone writes code is worth more than a week of meetings with the person holding the budget.
Three — how the work moves today, including the parts that are not written down
Trace one real case from beginning to end. One order, one enquiry, one patient, one application. Follow it through every hand it passes and write down each step, including the ones that embarrass you.
The steps that embarrass you are the important ones. The spreadsheet somebody maintains privately because the official system cannot do it. The WhatsApp message that triggers the whole dispatch process. The approval that officially requires a form and actually happens by walking over to someone's desk. Those workarounds are not failures of discipline. They are evidence of what the real process needs and the current tools do not provide, which makes them the most valuable design information in the building.
Two things to record as you go: where the case waits, and where information is retyped. Waiting points and retyping points are where the money is, and they are usually the entire justification for the project.
Four — what has to be true for this to have been worth doing
Decide, before you spend anything, how you will know in a year whether this was a good idea.
It should be a sentence with something checkable in it. The dealers stop phoning about order status. Month-end reporting takes a morning instead of three days. We can take twice the volume without hiring another coordinator. You do not need a precise target and you should not invent one to look rigorous. You need a statement specific enough that you and the person building it would agree, a year later, on whether it happened.
This does more work than it appears to. It is the thing you hold every proposed feature against. When somebody suggests adding notifications, or a second dashboard, or a mobile version, the question is not "would that be nice" but "does that move the sentence". Most suggestions do not, and a project that can answer that question stays small.
Five — the constraints that are actually real
Write down the things that are genuinely fixed, and be honest about which ones are not.
- Money. Not a precise figure, but the order of magnitude and, more usefully, what happens if it costs more. Is there a hard ceiling, or a point past which you would want to stage the work over two years?
- Time. Is there a real date, driven by something external such as a contract, a season, a regulation or a system being switched off? A deadline that exists because it would be nice to have this by then is not a constraint, and treating it like one distorts every decision after it.
- Systems you cannot replace. The accounting package you are locked into for two more years. The machine on the factory floor that only speaks one protocol. Constraints you disclose can be designed around. Constraints discovered in month three are change requests.
- People. Who will maintain this after launch, and how technical are they? A team with nobody technical needs different choices from a team with a developer in it.
- Rules. Anything in your industry that dictates how data must be held, who may see it, or how long records must be kept.
The temptation is to hold the budget back so that quotes come in lower. It usually produces the opposite of what you want. A supplier who does not know the ceiling will either propose the largest reasonable version, or guess low and discover the gap halfway through. Naming a range lets someone tell you what is achievable inside it, which is the conversation you actually want.
What you do not need to work out
This list matters as much as the one above, because most people arrive having done work that will be thrown away.
| You do not need | Why not |
|---|---|
| A feature list | Features are answers. Bring the problem and let the answers be argued about. A list decided in advance is a set of assumptions nobody can question without appearing to disagree with you. |
| A technology choice | Unless you are constrained by something you already run, choosing the stack before the problem is understood is choosing a tool before knowing the job. |
| Designs or wireframes | Useful for showing what you mean, harmful when treated as decided. If you sketch, label it a sketch. |
| A precise budget breakdown | A range is enough. A breakdown across phases you have not scoped is a fiction with decimals in it. |
If you have already done these, nothing is lost. Bring them, and be clear which parts you would defend and which parts were placeholders.
An illustrative example
Consider a distributor with 12 staff. The stated request is a mobile app for their sales representatives.
Working through the five points changes the shape of it. The problem sentence turns out to be that representatives phone the office to check stock before promising a delivery date, and get it wrong when the office is busy. The users are eight representatives and two people in the office who currently answer those calls. Tracing one order shows that stock is accurate in the accounting system but only updated there overnight, so even a perfect app would have been showing yesterday's numbers. The success sentence is that representatives stop promising dates the warehouse cannot meet. The constraint is that the accounting system stays for at least two years.
The overnight update is the discovery that matters, and it changes the project. Building the app first would have produced software that gave confident, wrong answers faster than before. The example is hypothetical, but that pattern is not unusual: the first thing you find when you trace the process is that the thing you were about to build sits on data that is not ready to support it.
Common questions
Is this not the developer's job? Part of it is. Any developer worth hiring will run their own version of this before quoting, and if they do not, that is worth noticing. But they can only ask; you are the only source for the answers. Arriving with them makes the process faster and cheaper, and it means the first conversation is about what to build rather than about basic facts.
How long should this take? An afternoon for something small. A week, spread out, for something that touches several departments — most of which is time spent watching how the work actually happens rather than time spent writing.
What if I genuinely do not know some of it? Write unknown and move on. A stated unknown is information. It tells whoever is scoping the project where the risk sits, and it will be dealt with early. An unknown you paper over gets discovered at the worst moment.
We already have a supplier we trust. Is this still worth doing? More so, if anything. Trust removes the need for the document to be defensive, which is what makes it useful. It becomes a shared description of the problem rather than a specification you are holding someone to.
The short version
- Write the problem in one sentence with no solution in it. If you cannot, that is the first thing to fix.
- List who will actually use it, and speak to two of them before anything is built.
- Trace one real case end to end, and record where it waits and where information is retyped.
- Decide the sentence that will tell you in a year whether this was worth doing, and hold every feature suggestion against it.
- Name the real constraints, including the budget range. Withholding it costs you more than it saves.
- You do not need a feature list, a technology choice, designs or a costed breakdown. Those are answers, and it is too early for answers.
Where to take this next
If you have not yet settled whether this is a website, an application, or something you should buy rather than build, that decision comes first and takes about the same amount of time: website, web application or custom software.
If you have the five answers and want to turn them into something you can send to a supplier, the next step is putting them in a document. How we work describes what we do with that information in the first stage of a project.
# Visual recommendations
Concepts only. Hairline drawing in ink and brass, per 10-DESIGN-SYSTEM.md. No stock photography.
Hero visual — the cost of a late decision
Concept. A rising stepped line across four labelled stages: conversation, document, design, built. At each step the same small question sits above the line, "can a customer have two addresses?", and the block underneath it grows from a single square to a stack of eleven. The line is not a graph and carries no axis numbers, because there is no data behind it and there should not appear to be.
Purpose. Establishes the article's premise in one look: the same decision, made later, is a larger object.
Composition. Wide, roughly 3:1, four steps, brass used only for the question label.
Alt text. The same small question costs progressively more the later it is answered: trivial in conversation, a document edit at the writing stage, a redesign later, and rework once eleven screens depend on it.
Supporting visual — tracing one case
Concept. A horizontal path following one order through six hands, drawn as labelled nodes. Two node types are marked differently: waiting points shown as a hollow node, retyping points shown as a node with a small return arrow above it. One node sits slightly below the main line, labelled the spreadsheet nobody mentions, connected by a dotted line.
Purpose. Turns section three from an instruction into something the reader can copy directly onto paper for their own process.
Placement. Immediately after the "how the work moves today" section.
Alt text. One order traced through six steps, marking where it waits, where information is retyped, and the unofficial spreadsheet running alongside the official process.