The questions I ask before writing a line of code

Building has never been cheaper. AI tools and no-code platforms can turn an idea into working software in days, which is a good thing: it means you can test more ideas for less. What has not got cheaper is building the wrong thing. These are the questions I ask every founder before anything is built, in the order I ask them.

Who is the customer?

"Everyone" is a tempting answer, and it is not an answer. A product for everyone has no first customer, and without a first customer there is nobody to sell to on day one.

I push for a customer you could describe as a person. What job do they do? What size of business do they work in? What do they use today, and what would they have to stop using to use yours? If you cannot picture someone like that, the next step is not a build. It is a week of conversations.

Then I separate the user from the buyer. In business software they are often different people. The user feels the problem every day. The buyer signs off the budget and cares about cost, risk and how the decision looks to their own boss. A product can delight its users and still never get bought, so both need a reason to say yes.

The quickest way I know to get there is to ask about the last three people who told you they wanted this. What was their role? What kind of business? What did they say, word for word? If those three are alike, you have a customer. If they are all different, you have three ideas, and the first job is to pick one.

A good answer sounds like "operations managers at logistics firms with 20 to 100 staff who still plan routes in spreadsheets". A weak answer sounds like "small businesses".

What problem costs them money?

People complain about plenty of things they will never pay to fix. The problems that get a budget are the ones already costing money: hours lost every week, mistakes that lead to refunds, sales that slip away, or a compliance gap that could stop a contract.

So I ask the customer, not the founder, to put a rough number on it. How many hours a week does this take? Who does it, and roughly what do they cost? How often does it go wrong, and what happens when it does? Ten minutes of arithmetic with a real customer tells you more than any market sizing slide.

The number does not need to be precise. It needs to be big enough that your price looks small next to it. If the problem costs a business a few hundred pounds a year, a product priced at a few thousand will be a hard sell however good it is.

Signs the answer is weak:

• The customer agrees the problem is annoying but has never tried to fix it.
• They already have a workaround that costs them almost nothing.
• The cost appears in your pitch deck but never in the customer's own words.

Would they pay, and how do we know?

People are polite about other people's ideas. "I would definitely use that" costs nothing to say, and survey answers about what someone might buy one day are a guess about a guess.

Evidence that counts costs the customer something:

• Money: a deposit, a paid pilot or a pre-order.
• Time: an hour walking you through how they work today, or a regular call while you build.
• Commitment: a letter of intent, an introduction to the person who holds the budget, or access to their real data.

Before anything is built, I test this directly. Describe the product plainly, say the price out loud and ask for the next step: "Shall we start a paid pilot next month?" Asking "would you pay for this?" without a number tells you nothing. A polite no is still useful. You learned it at the cost of a conversation, not a build.

A good answer is two or three customers who have paid, or committed in writing to pay, before the product exists. A weak answer is a waiting list of email addresses and a lot of encouragement.

What is the smallest test?

The smallest test is the cheapest thing that could prove the idea wrong. It is not the smallest version of the whole product. It is the smallest experiment that would change your mind.

Often the first version is not software at all. It might be a landing page with a price and a button to book a call. It might be a spreadsheet, with a person quietly doing the work by hand behind it. It might be a weekly report you put together manually and email to five customers. If customers pay for the manual version, software makes it cheaper to deliver. If they will not pay for the manual version, software will not save it.

Say the idea is a tool that chases unpaid invoices for small firms. The smallest test is not an app. It is doing the chasing yourself for five businesses for a month, for a fee, and writing down what worked. If they ask to carry on, you have a product specification written by real customers.

When the test does need software, this is where AI tools and no-code platforms earn their keep. Build it fast and cheap first, and build it properly once it has proved itself. My guide to choosing between building, buying and no-code covers when each makes sense.

What would make us stop?

This is the question founders least like answering, and the one that saves the most money.

Before we start, we write down the result that would make us stop or change direction. For example: "If fewer than three of the ten customers we speak to will pay for a pilot, we stop and rethink." It has to be agreed up front. Once money and hope have been spent, every result starts to look like a reason to carry on.

Having run budgets and a P&L, I would much rather a project fails in week two than in month nine. An idea that fails a cheap test has done its job. The expensive failures are the ones nobody was allowed to call.

Stopping well looks like this:

• You write down what you learned, while it is fresh.
• You thank the customers who gave you their time, and tell them what you found.
• You look for the next idea in your notes. It is often hiding in a problem a customer mentioned in passing.

Stopping is not the opposite of progress. It is the test working.