How to choose a software development partner / Vet a partner
Questions to ask a software development partner before you hire
A good pitch tells you a company can sell. It does not tell you they can build. These questions change the conversation from the sales pitch to how the team actually works, which is the only thing that predicts how your project will go.
Published July 27, 2026. Editorial.
Key takeaways
- Ask how they scope a vague problem, since most real work starts vague.
- Ask who writes the code, and make sure the senior people in the sales meeting are the ones on your project.
- Ask what they did on a project that went wrong, because that reveals how they behave under pressure.
- Ask how they measure success, and listen for outcomes rather than hours or tickets.
Every development company can present well. Fewer can show you how they actually operate when the work gets hard. The questions below are designed to go beyond the sales pitch. Ask them, then listen for specifics. Vague, polished answers are themselves an answer.
How do you scope a project when the requirements are unclear?
Most real work starts vague. What separates a strong team from a weak one is what they do with that vagueness. A weak team asks you to hand them a complete spec and then builds exactly it, even when it is wrong. A strong team helps you make the plan, asks the questions that expose the risky assumptions, and starts small to learn before committing. Listen for a real process here, not just "we are flexible." How to scope the first project covers what good scoping looks like.
Who will actually write the code?
This is the question that exposes the most companies. Many put their most senior people in the sales meetings and staff the actual project with juniors. Ask directly: are the people I am talking to the people who will build this? Ask to meet the engineers who would be on your team. Seniority is the biggest predictor of whether a project is released, so you want to confirm the senior people are real, assigned to you, and still there after the sales pitch.
Tell me about a project that went wrong.
How a team behaves on a bad week tells you more than how they behave on a good one. Ask for a real example of a project that ran late or a decision that turned out wrong, and what they did about it. A trustworthy partner will tell you a real story, including the uncomfortable part, because they have learned from it. A team that claims nothing has ever gone wrong is either inexperienced or not being honest with you. Warning signs when hiring a software development agency lists the answers that should worry you.
How do you measure whether the work is succeeding?
Listen for outcomes, not activity. A weak answer counts hours logged, tickets closed, or story points completed. A strong answer talks about whether the product does what it needed to do for your users and your business. We wrote about why this matters in measure engineers by outcomes, not output. The way a team measures success is the way they will actually behave, so this question predicts a lot.
How will you work with our existing team and systems?
If you already have engineers, security rules, and a way of working, you want a partner that fits into them rather than working alone and handing over code without discussion. Ask how they work inside your team: do they join your standups, use your repositories, follow your review rules, adopt your definition of done? A partner that plans to work inside your process will cost you far less coordination than one that gives you code you have to rework to fit.
What happens at the end of the engagement?
Ask what handover looks like. Good partners build so your team can own the code after they leave: clear documentation, no hidden knowledge, no dependence on them to keep the product running. A partner that quietly makes you dependent on them has a business reason to, and it is not your interest. You want to finish the engagement stronger, and free to continue without them.
How to use these
Do not treat this as a checklist to complete. Ask the question, then follow the answer with "can you give me a specific example." Specifics are hard to fake. The team that answers with real stories, names the senior people on your project, and talks about outcomes is the team most likely to build you something that works. The main guide puts these questions in the wider context of choosing well.
Common questions
What questions should I ask a software development partner before hiring?
Ask how they scope a vague problem, who will actually write the code, what they did when a project went wrong, how they measure success, how they work with your existing team, and what handover looks like at the end. Follow each answer by asking for a specific example.
How do I know if the senior people in the sales pitch will be on my project?
Ask directly and ask to meet the engineers who would be assigned to you. Many companies staff sales with senior people and projects with juniors, so confirm the seniority you see is the seniority you get, in writing if needed.
What is the most revealing question to ask?
Ask them to describe a project that went wrong and what they did about it. How a team behaves under pressure predicts your experience far better than how they present on a good day. A real, slightly uncomfortable story is a good sign.
How should I ask a software development partner how they measure success?
Ask directly and listen for outcomes, not activity. A weak answer counts hours logged, tickets closed, or story points completed. A strong answer talks about whether the product does what it needed to do for your users and your business, which predicts how the team will actually behave.
Should I ask a software development partner what happens after the engagement ends?
Yes. Ask what handover looks like, since a good partner builds so your team can own the code after they leave, with clear documentation and no hidden knowledge. A partner that quietly makes you dependent on them is protecting its own business, not your interest.
How do I follow up on a vague answer during vetting?
Ask for a specific example after every answer. Specifics are hard to fake, and the team that answers with real stories, names the senior people on your project, and talks about outcomes is the team most likely to build you something that actually works well.
Should I ask a potential partner how they scope unclear requirements?
Yes, ask directly, since most real work starts vague. A weak team asks you to hand them a complete spec and builds exactly it, even when it is wrong. A strong team helps make the plan, asks the questions that expose risky assumptions, and starts small to learn before committing.
How should I ask about a partner's fit with my existing team?
Ask how they work inside your team: do they join your standups, use your repositories, follow your review rules, and adopt your definition of done. A partner that plans to work inside your process will cost you far less coordination than one that gives you code you have to rework.
Related reading
Red flags when hiring a software development agency
The wrong agency costs you months, not just money. Here are the warning signs worth checking before you sign a contract, not after.
How to choose the right external development team
Hiring an outside team is a decision with serious consequences. The wrong partner costs you time and progress you cannot get back.
More in Vet a partner
How to evaluate a development team's engineering quality
You do not need to be an engineer to judge engineering quality. You need to know which signals to look for. The strongest ones are how a team makes decisions, how they handle change, and whether their past work still runs well for the people who own it now.
How to run a paid trial project before you commit
References and interviews only tell you so much. A small, paid, real piece of work tells you how a team actually builds, communicates, and handles the difficult middle stage. It is the most informative vetting step you can take, and it is worth paying for.