Seven Questions to Ask Before Hiring a Development Team

This is a slightly odd article: we're a development studio ourselves, teaching you how to vet development studios — effectively handing you the exam questions for interviewing us. But we've thought it through: a team that gets stumped by these questions shouldn't be taking your project in the first place, and a team that can answer them is worth knowing.

First, a hard truth: portfolios have almost no discriminating power. A portfolio only tells you "this team has built something similar" — not whether the process went smoothly, whether anyone maintained it after launch, or who ended up owning the code. The real discrimination is in the questions. Here are the seven we ask when we outsource work ourselves.

The Seven Questions

1. "What does your development process look like? How often do I see progress?" A good answer is a concrete cadence — for example, a working version you can actually click through every two weeks. A bad answer is "we'll show you when it's done" — which means you won't find out it went sideways until the last possible moment.
2. "How do you test before launch?" Listen for the keywords: automated tests, real payment-flow verification, on-device checks. If the answer is "we'll ask the client to assist with acceptance testing," that translates to "you test it yourself."
3. "Who owns the source code and the data? How is that written into the contract?" A vague answer here is an immediate disqualification. A finished system without the source code is a house without the deed.
4. "When something breaks after launch, who handles it, and what does it cost?" A good team has a defined warranty scope and maintenance plans; a bad team starts saying "we'll figure it out when it happens."
5. "What does this quote include — and what does it not include?" The point isn't whether the price is high or low; it's whether they're willing to break the quote apart. Teams that lay it open tend to work transparently too; a quote that's one undifferentiated lump sum means the change-order fees will teach you a lesson later. Pair this question with our piece on reading quotes.
6. "Who actually does the work?" At some firms, a senior consultant closes the deal and a subcontractor's subcontractor writes the code. You have the right to know whose hands your code comes from.
7. "What's a project you botched, and how did you handle it?" This is the most important of the seven. Nobody does this work for years without failures. A team that answers "none, actually" is either too green or not honest — both dangerous. A team willing to talk about failure, and able to explain how they remediated it, is the team that stays and carries the weight when things go wrong.

When choosing a development team, don't measure how beautifully they tell their successes — measure how honestly they tell their failures.

Beyond the Answers, Watch the Behavior

Beyond the questions, the quoting process itself is the best trial period. Watch for three behavioral signals. First, do they ask you questions back? A good team probes your business goals, your users, and what success looks like before quoting; a team that prices your requirements without a single question is planning to build something that merely resembles what you asked for. Second, do they dare to say "we'd advise against this"? A team willing to cut requirements at the quoting stage will save you money during the engagement too. Third, the quality and speed of their replies — the sales stage is when a vendor is at their most attentive. If they're already leaving you on read or answering the wrong question now, it only gets worse after signing.

One Last Reminder: You're a Variable Too

Honestly, half of a project's success sits on the client's side: are the requirements thought through? Is there one person who can make decisions? Do assets and feedback arrive on time? Picking a good team is only half the job; the other half is being a good client. If you want to figure out what your half requires, start with writing a good requirements document — clear requirements make even the quotes far more accurate.