Choosing a full-service software partner is one of the highest-stakes decisions a founder or CTO makes. The cost of a wrong choice is not just money — it is 6-18 months of lost time, a codebase you cannot own, and a product that does not work the way you envisioned.
Most due diligence focuses on the wrong things: portfolio aesthetics, price, how responsive they are in the sales process. The things that actually predict whether a partnership will work are harder to evaluate but equally observable. These seven questions get at them.
1. Who specifically will work on my project, and what have they shipped?
Many agencies sell you on their senior partners and deliver your project to mid-level or junior engineers. Ask for the names and CVs of the specific people who will be on your engagement, not the company's general team.
Ask what they have shipped. Not projects they contributed to — products they owned end-to-end. The ability to own a product through launch and into production is a different skill than contributing to one. You want people who have done it.
2. How do you handle a situation where the requirements are wrong?
Build shops execute requirements. Engineering partners challenge them. Ask a potential partner to describe a time they pushed back on a client's spec and what happened.
If the answer is that they built what was asked, you are looking at a body shop. If the answer describes a diagnosis process — understanding the underlying problem before deciding on the solution — you are looking at a partner. The distinction matters enormously over the course of a multi-month engagement.
3. What is your quality bar, and how do you enforce it?
Ask to see their CI/CD pipeline for a recent project. Ask what their test coverage policy is. Ask how they handle technical debt.
Good answers involve automated gates — builds that fail if coverage drops, linting that blocks merges, performance budgets that are measured on every PR. Bad answers involve words like 'we review everything manually' or 'we will clean it up after launch.'
Code that ships without automated quality gates accumulates debt exponentially. You will spend the second year of a project paying for shortcuts taken in the first three months.
4. How do you think about AI in this product?
Even if you are not building an AI product, this question is revealing. A senior engineering partner will have an opinion about where intelligence could improve the product, what data model would support it, and what the trade-offs are. A body shop will say 'we can integrate whatever APIs you need.'
AI is becoming a layer in every serious software product. A partner who has not thought about where it belongs in yours — and cannot articulate why — is either not thinking at the right level of abstraction or does not have the capability.
5. What does handover look like at the end of the engagement?
Ask about documentation, onboarding material for your internal team, and what ongoing support looks like after handover. A partner who has thought carefully about this will have a process. One who has not will give vague answers about 'knowledge transfer sessions.'
The goal of every engagement should be a codebase your team can own and extend without the partner. If a partner's incentive is to keep you dependent on them, their architectural choices will reflect that — abstraction layers that only they understand, documentation that is deliberately incomplete.
6. Can you show me a post-mortem from a project that went wrong?
Every serious team has post-mortems. Ask to see one — anonymised if necessary. The quality of the post-mortem tells you more about the team's engineering culture than any portfolio piece.
Look for: honest identification of the root cause (not blame-shifting), systemic fixes rather than individual blame, and follow-up actions that were actually completed. A team that writes good post-mortems has the discipline to learn from failure rather than repeat it.
7. What will you tell me if this is going wrong?
This is the most important question. Ask how they communicate when a deadline is at risk, when a technical decision they made is not working out, or when the project is more complex than initially scoped.
You want a partner who surfaces problems early, not one who manages your perception of progress until the situation is unrecoverable. Ask for a specific example of how they handled a difficult conversation with a previous client.
The ability to have hard conversations honestly is what separates a partner from a vendor. Vendors manage relationships. Partners manage outcomes.
These questions will make some agencies uncomfortable. They are designed to. The right partner will welcome them — and probably have their own hard questions for you in return.