The five questions I ask before writing a line of code.

When someone writes to me about building a system, the last thing I ask is what they want the system to do.

Not because it doesn't matter. Because the answer to that question changes three times during a project, and there are five others that don't change and that decide whether it goes well.

I'm putting them here for two reasons. One, so you know how I work before you risk money with me. Two, because answering them for yourself puts you in a better position with any supplier, whether we work together or not.

1. How do you do it today?

Before what you want to happen, I need to know what happens now. Who receives it, who checks it, where it gets recorded, what happens when something comes in differently.

If the answer is clear, the project starts with half the risk removed. If the answer is "it depends" or "Marcela handles that", there's your first piece of work, and it isn't programming.

2. What happens if we do nothing?

It sounds like a salesperson's question in reverse, and it's the most useful of the five.

If the answer is "we carry on, uncomfortable but working", you have time and it's worth doing this properly. If the answer is "in three months we can't invoice", we're talking about something else and that has to be solved first, however inelegantly.

This question often reveals that the urgent problem isn't the one I was being told about.

3. Who decides?

I need a name. One person who can say "do it this way" without checking.

They don't have to be the owner or know anything about technology. They have to exist and be available. Projects that stretch rarely stretch on the hard part: they stretch waiting for definitions.

4. What's the one thing that absolutely has to work?

Every request has a list of twenty things. There's almost always one that, if it fails, makes the rest pointless.

Knowing which one changes the order things get built in. You start there, you test it with real people early, and everything else arranges itself around it. If nobody picked that one thing, everything gets built at the same priority, which is the most expensive way to work.

5. What is explicitly out of scope?

This is the most uncomfortable one and the one that protects both sides most.

Writing down what the project does not include avoids the "I assumed that was part of it" conversation, which is where trust breaks. And it closes no doors: what's out today can be done later, quoted separately, with a clear head.

A quote that only says what's included is incomplete.

If you can't answer them

More common than you'd think, and it isn't a bad sign: it's a sign of which stage you're at.

If several answers are missing, it isn't time to hire anyone to build yet. It's time to sit down and get organised, which costs no money and lowers the price of everything that follows.

I'll tell you if I see that. I'd rather lose a project than start one that's going to go badly, because the bad ones cost me too: time, reputation, and a relationship that breaks.

If you'd like to go through these five questions together, the first conversation is free and comes with no strings. Sometimes it ends in a project, and sometimes in a plan for six months from now.