Let me guess. You have a product idea that you are genuinely excited about. You have told a few people. They nodded. Maybe they even said “you should build that.”

So now you are thinking about hiring a developer.

Before you do, I need you to sit with five questions. Not because I want to slow you down. Because I have seen what happens when founders skip them, and it is expensive, demoralising, and completely avoidable.

1. Have you validated the problem, not just the idea?

There is a difference between people saying “that sounds useful” and people actually changing their behaviour to solve a problem.

Before you write a single line of code, or pay someone else to, you need evidence that the problem is real and painful enough that someone will pay to fix it. Not a survey. Not a focus group. An actual conversation where someone tells you they have been cobbling together spreadsheets, WhatsApp groups, or workarounds because nothing out there does what they need.

If you cannot name five people who have this problem right now, you are not ready to hire a developer. You are ready to do more research.

2. What does your MVP actually need to do? Nothing more.

I ask founders to describe their MVP and most of them describe a version 3.

An MVP is not a product with all the features. It is the smallest version of your product that lets a real user do the one thing that matters, well enough to tell you whether you are onto something.

Write it down. One sentence. “A user can [do this thing] and [achieve this outcome].”

If you cannot write that sentence, your developer will write it for you. And they will write it wrong, because they do not know your users, your market, or your vision the way you do.

3. Do you have a clear product spec, or are you expecting the dev to figure it out?

Developers are not product managers. The best ones will ask good questions. But if you hand someone a vague brief and a budget, you will get a vague product.

A basic spec does not need to be a 40-page document. It needs to answer: who is this for, what can they do, what happens when something goes wrong, and what does success look like?

If writing this feels hard, that is not a sign you need help. That is a sign you need to think more before you build. Spend a week on this. It will save you months.

4. How will you evaluate their work if you cannot read code?

This one makes founders uncomfortable, but it is the right question.

You do not need to understand the code. But you need a way to evaluate whether your developer is doing good work. That means asking them to explain decisions in plain English. It means knowing what “done” looks like before you start. It means checking in on progress not by reading pull requests but by looking at what the product actually does week on week.

If you have no way to evaluate the work, you have no leverage. And a developer who knows that will take their time, cut corners, or both.

5. What happens if they disappear in month three?

This is not pessimism. This is planning.

Developers leave. Agencies fold. Freelancers get a better offer. It happens more than you think, especially in early-stage projects where the work is ambiguous and the stakes feel low.

Before you hire, ask yourself: is the code going to be documented? Who owns the repositories? If I had to hand this to someone else in six months, could I?

If the answer is “I have no idea,” that is something to sort out before you sign a contract. Not after.

The honest truth

Most founders who come to me have already made one of these mistakes. That is not a failure. It is just where the market is right now: full of excitement and short on process.

The good news is that answering these questions is not complicated. It just requires you to slow down and think like someone who has built before.

If you want to talk through where you are, I offer a free 30-minute call. No pitch. Just an honest look at where you stand and what you need before you spend a single penny on development.