Seven questions to ask before hiring any developer

Hiring someone to build software is hard precisely when you cannot evaluate the work yourself. You can still evaluate the answers to these. Ask them of me too.

1. Who owns the code?

The answer should be you, in writing, in a repository you have an account on from day one. If the code lives somewhere you cannot see and you would lose it by leaving, you are renting your own product.

2. What happens if you disappear?

Everyone gets ill and everyone eventually moves on. Ask what another developer would need to pick this up. "The code is documented and the deployment is scripted" is a real answer. "That won't happen" is not.

3. What is not included in this price?

If the answer is "nothing, it's all covered", they have not thought about it. Cloud hosting, domains, app-store fees, payment-gateway commission and message costs are always paid by someone. Find out now, not in month three.

4. What would you cut if the budget were half?

This is the best question on the list. Someone who has actually shipped things will answer immediately and specifically, because they have made this trade before. Someone who has not will say it all matters.

5. How will I see progress?

You should be looking at something that runs, weekly, from the second or third week. Not screenshots and not a percentage. A long silence followed by a big reveal is where projects go to fail.

6. What have you got wrong before?

Anyone with a decade of experience has broken production, under-estimated a project or shipped a bug that cost someone money. A candid, specific answer tells you they learned something. A blank one tells you they either have not done much or will not tell you when it happens on yours.

7. Who exactly writes the code?

Worth asking plainly in 2026. Some of it will be AI-assisted at almost any studio — that is fine and it makes things faster. What you want to know is whether a human reads all of it before it goes live, and whether that human will still be reachable when something breaks.

My own answer to all seven is on this site. If any of it stops being true, it should stop being written here.

One more, for free

Ask whether they will tell you not to build something. A developer whose advice is always "yes, and it'll cost this much" is a supplier. One who occasionally says "you don't need that yet" is worth considerably more than they charge.

Three answers that should worry you

Beyond the questions themselves, some replies are informative in ways the speaker does not intend.

• “That won't be a problem.” To any question about risk. Every project has problems; someone who has shipped things knows which ones are likely and will name them.
• A quote with no questions attached. If a price arrives before anyone has asked how many users, what it integrates with, or what happens to your existing data, the number is decoration.
• “You wouldn't understand the technical details.” Anything in this field can be explained to an intelligent person who does not do it for a living. Refusing to is either an inability to explain or an unwillingness to be checked.

What to agree in writing before money moves

Not a forty-page contract. A single page covering six things prevents almost every dispute I have seen or heard about.

1. What is being built, as a list specific enough to tick off. “A booking system” is not a scope.
2. What is not included, explicitly. This line saves more arguments than any other.
3. Who owns the code and the accounts. You, in a repository you have access to from day one.
4. Payment schedule tied to visible progress, not to dates. You should be able to see something running before each payment.
5. What happens to bugs after launch, and for how long.
6. How either side ends it, and what you keep if they do.

How to tell it is going well, three weeks in

You will not be able to judge the code. You can judge these, and they correlate better than most people expect.

• You have seen something running — not a screenshot, not a percentage — in at least two of the three weeks.
• They have said no to something, or proposed a cheaper way to do it.
• Questions come back to you as questions, rather than assumptions being made silently and revealed later.
• Bad news arrives early and unprompted. A developer who only reports good news is not having a smooth project; they are managing you.

And if it is going badly

Stop early. The instinct is to keep paying because of what has already been spent, and that instinct is expensive — the money is gone either way, and the only question is whether more follows it.

This is exactly why the payment schedule should be tied to visible progress and why the code should be in your repository from the first week. Both make leaving cheap, which is precisely when you find out whether the arrangement was fair.