Choosing a software development vendor is mostly an exercise in reducing uncertainty. You are trying to predict how a company will behave over six months of real work based on a few conversations and a proposal. The good news is that the right questions surface most of what matters quickly. The wrong ones (usually about years in business or client logos) tell you almost nothing.
Below are twelve questions grouped by what they actually measure: technical judgment, how the work gets delivered, and how the commercial relationship holds up when things get hard. Ask them directly, and pay as much attention to how a vendor answers as to what they say.
Questions about technical fit and judgment
The goal here is not to test trivia. It is to find out whether the vendor can reason about your specific problem rather than reach for whatever stack they always use.
1. What would you build differently if this had to scale to ten times the load, and what if it never did?
A strong vendor will describe trade-offs, not a single right answer. You want someone who avoids over-engineering a simple internal tool and who does not casually skip architecture that a customer-facing product genuinely needs.
2. Which parts of our project are the riskiest, and why?
If a vendor tells you everything is straightforward, be cautious. Every real project has soft spots: an integration with a flaky third-party API, unclear requirements, a data migration, a compliance requirement. Naming these early is a sign of experience.
3. How do you decide when to use AI versus conventional code?
This matters more every year. A capable partner treats AI as one tool among several, not a default. Ask when they would use a large language model, when they would use simpler rules or classic automation, and how they handle cases where the model is wrong. Vague enthusiasm is a red flag; specific reasoning about accuracy, cost, and failure modes is what you want.
4. Can you show me code or a system you built that resembles our problem?
Portfolios of polished screenshots are easy to produce. Ask to see something closer to the machinery: a repository, an architecture diagram, or a walkthrough of a comparable build. You are checking for real depth, not marketing.
Questions about process and delivery
Most projects do not fail on technical ability. They fail on communication, scope, and the slow drift between what you meant and what got built. These questions test the operating system behind the work.
5. What does a typical week look like once we start?
You want a concrete rhythm: how often you will see working software, how progress is reported, who you talk to, and how decisions get made. A vendor who cannot describe their own cadence usually does not have one.
6. How do you handle changing requirements mid-project?
Requirements always change. The question is whether the vendor has a sane process for it. Look for a clear approach to scope changes, transparent impact on timeline and cost, and no drama. A partner who treats every change as a fight, or who silently absorbs everything and then blows the deadline, will be painful either way.
7. Who exactly will do the work, and will that change?
Some firms sell you with senior people and staff the project with juniors. Ask who is assigned, their experience level, and whether they are shared across other clients. This is not about demanding only senior engineers; it is about knowing what you are actually buying.
8. How do you test, and what happens when something breaks in production?
Ask about automated testing, code review, and their process when a bug reaches live users. A serious vendor has a plan for incidents and does not treat quality as an afterthought you pay extra for.
9. What will I own, and how will I get it?
Confirm that you own the code, the infrastructure accounts, and the documentation. Ask how handover works and whether you could take the project to another team without a rewrite. Vendors who make themselves impossible to leave are a long-term liability.
Questions about the commercial relationship
The last group is about incentives and what happens after launch, when many vendors quietly disappear or become expensive.
10. How do you price, and what makes the number go up?
Fixed price, time and materials, and monthly retainers all have valid uses. What matters is that the vendor can explain their model clearly and tell you the specific things that would increase the cost. Ambiguity here becomes disputes later.
11. What does support look like after we launch?
Software is not done at launch. Ask about response times, ongoing maintenance, dependency updates, and how much a support arrangement costs. A build with no support plan is a half-finished purchase.
12. Can I speak with a client whose project did not go smoothly?
Anyone can give you a happy reference. Asking for a harder story tells you how the vendor behaves under pressure and whether they take responsibility. If they can talk honestly about a project that had problems and how they handled it, that candor is worth more than a wall of testimonials.
How to read the answers
Once you have asked, weigh the pattern rather than any single response. A trustworthy vendor tends to be specific, comfortable naming risks and trade-offs, and honest about limits. A weaker one leans on reassurance, avoids concrete detail, and agrees with everything you propose.
Consider a common scenario. A mid-size operations team wants to automate an approval workflow that touches three internal systems. One vendor promises to have it all done in a few weeks with a confident nod. Another asks about your data quality, flags the messiest integration, proposes a small first phase to prove the approach, and explains what would extend the timeline. The second vendor sounds less impressive in the meeting and is almost always the better bet.
You will not eliminate all uncertainty before you sign. But twelve honest questions, asked directly, will tell you most of what you need to know, and will filter out the vendors who cannot back their pitch with substance.