Choosing a development partner is part technical decision, part relationship. You'll spend months working closely with these people, trusting them with your budget and often with your customers' data. Good studios welcome hard questions — and their answers tell you far more than a polished case study.

Here are twelve questions, grouped by what they reveal, with notes on what to listen for.

About the work

  • Can you show something similar you've built — and what you'd do differently now?
  • Who designs, and who builds? Are they on the same team?
  • What will you need from us, and when?

The first question is the most revealing. A team that can talk honestly about past mistakes has learned from them. The second matters because hand-offs between separate design and development teams are where many projects lose quality. The third tests whether they've thought about your role — content, decisions, access — not just theirs.

About the people

  • Who exactly will work on our project, day to day?
  • Who do we talk to when something goes wrong?
  • How do you handle disagreements about scope or priorities?

Ask to meet the people who will actually do the work, not only the people who sell it. Listen for a named point of contact and a clear route for escalation. A good answer to the third question describes a process — written scope, trade-off conversations — rather than promising that disagreements never happen.

About the process

  • What will we have in hand after the first two weeks?
  • How often will we see working software, not just updates?
  • How do you estimate, and what happens when an estimate is wrong?

Early, tangible output — a scope document, a clickable prototype, a first working screen — is a good sign. Regular demos of real software mean problems surface early. And every honest studio has been wrong about an estimate; what matters is that they tell you early and offer options, rather than quietly cutting corners.

About afterwards

  • Who owns the code, designs and accounts when the project ends?
  • What does support look like after launch?
  • How would another team take over if they needed to?

You should own your code, designs, domain and hosting accounts outright, and the contract should say so. Support should be defined: response times, what's covered, what it costs. The last question is a good test of quality — a studio confident in its work will talk about documentation, clean repositories and hand-over notes without hesitation.

Listen less to the confident answers and more to the specific ones.

Red flags

  • A fixed price for a large project before anyone has asked detailed questions.
  • No access to the work in progress until the end.
  • Vague answers about who will do the work.
  • Reluctance to put ownership of code and accounts in writing.
  • Promises that everything is possible, on any timeline.

What good answers sound like

Concrete and calm. A good partner names the people, describes the rhythm, admits where estimates usually slip and explains how they handle it. They ask you as many questions as you ask them. Vague enthusiasm is easy; specifics are earned.