The questions most founders ask in a first call — what's your rate, how long will it take, what technology do you use — produce answers that all sound the same. Everyone quotes, everyone estimates, everyone names a framework.

These twelve produce answers that differ, and the differences are the information. None require technical knowledge to evaluate. Part of how to hire a developer for your MVP.

1. "If you had to cut 40% of this, what would you go?"

The single most revealing question in the set.

Strong: names three specific things and explains which assumption each fails to test. "I'd drop the admin panel, the second user role, and in-app messaging. None of them affect whether people complete a booking, and together they're probably a third of the build."

Weak: "Whatever you'd prefer." Or worse, genuine enthusiasm for the whole list.

Someone who agrees to everything is telling you they'll build whatever you say. That sounds like service and is the most expensive trait a developer can have.

2. "Walk me through what happens in the first two weeks."

Strong: specific and sequenced — discovery, wireframes, technical planning, a first reviewable increment, a milestone review.

Weak: "We'll get started on development."

Vagueness here reliably predicts vagueness later.

3. "How will I know you're making progress?"

Strong: a staging URL you can open any time, a demo cadence, a visible board.

Weak: "I'll email you updates."

If you can't see it working, you're taking progress on trust — and by the time trust turns out to be misplaced, the budget is gone.

4. "Who will actually write the code?"

Especially for agencies. Sold-by-seniors, built-by-juniors is standard economics, not fraud — but it should be disclosed.

Strong: a name, their role, confirmation they're on it throughout, and who attends calls.

Weak: "One of our senior team." Get a name.

5. "What's the riskiest part of this project, and when will you tackle it?"

Strong: identifies something specific — usually an integration or an unknown in an external system — and plans to do it early.

Weak: "Nothing's risky, it's all straightforward."

Nothing is ever all straightforward. Doing the risky part first means you find out about problems in week two, when the plan can still change. Timelines mostly slip because of what nobody looked at early.

6. "Tell me about a project that went badly and what you did."

Strong: specific, includes their own contribution, and names the process change that followed. "I underestimated a payment integration by three weeks because I assumed their sandbox supported refunds. Now I verify that before quoting."

Weak: a disguised humblebrag ("the client kept changing their mind") or a claim that none have.

Everyone has one. A developer who says otherwise is inexperienced or not being straight with you.

7. "Is there an off-the-shelf way to do this without hiring you?"

Strong: a real answer, including when it's yes. "Honestly, for this you could get to market on no-code in three weeks. Custom makes sense once you have the matching logic."

Weak: insisting custom is the only option for a straightforward CRUD app.

Someone who'll talk you out of work when it's right is someone who'll tell you the truth when it costs them. No-code vs custom is where that comparison actually lands.

8. "What's not included in your quote?"

Strong: a clear list — design revisions beyond a number, content, third-party subscriptions, app store fees, post-launch support.

Weak: "Everything's included."

Nothing includes everything. A proposal with no exclusions section isn't a plan. This is the core idea in red flags in a development proposal.

9. "What happens when I want to change something mid-build?"

Strong: a described process — estimate the change, you decide to add time, remove something else, or defer it.

Weak: "We're flexible, just let us know."

Flexibility with no process is how schedules quietly slip. You want the change to be visible, not absorbed.

10. "What do I own at the end, and whose name are the accounts in?"

Strong: immediate and unambiguous. You own everything; accounts are created under your company from day one with them added as collaborators.

Weak: hesitation, "we host it for you," or a preference for keeping the repository on their side.

This is the question with the highest cost of getting wrong. Who owns the source code covers what to insist on.

11. "What does handover look like?"

Strong: a concrete list — repo with full history, deploy instructions, environment variables documented, database schema and migrations, design files, credentials.

Weak: "We'll send you the files."

The handover checklist is what a good answer sounds like in full.

12. "Can I speak to two founders you've worked with?"

Strong: yes, with names, within a day or two.

Weak: hesitation, or offering written testimonials instead.

When you get the call, ask behavioural questions rather than satisfaction questions: did they stay on budget, did they push back when you were wrong, what happened the first time something broke, would you hire them again.

What to do with the answers

Ask all twelve of three candidates who've received the identical one-page spec. Then compare.

You're not looking for the person who gives the most impressive answers. You're looking for the one who's most specific — specific about what they'd cut, specific about the risk, specific about what's excluded, specific about who builds it. Specificity is the trait that survives contact with a real project.

Vague confidence is the thing to be worried about, and it's the thing that interviews well.

If you'd like these questions asked on your behalf by someone who isn't bidding, get in touch.