You already know the vetting ritual. You studied the portfolio, took the three reference calls they handed you, scanned the reviews, and sat through a sharp technical presentation from people who seemed genuinely good. Then you signed — and six months in, you were managing a team you didn’t recognize, chasing status you couldn’t trust, on a timeline that had quietly tripled. If you’ve evaluated a software development partner before and still got burned, it wasn’t because you skipped a step. It’s because the standard checklist is built to be passed.
Portfolios show the best five percent of the work. References are hand-picked to say yes. The people in the sales demo are rarely the people who write your code. None of it tells you how a partner behaves when a project is late, an engineer quits, or your interests stop lining up with theirs. This diagnostic does — twelve questions that surface behavior instead of credentials, and, just as importantly, what the way they answer tells you.
Why the standard checklist fails
The three signals most CTOs lean on are the three easiest for a software engineering partner to manage. A portfolio is a highlight reel; you never see the engagement that collapsed. References are a curated list of clients who will say the right thing — no vendor hands you the account that’s furious with them. Reviews can be solicited, incentivized, and timed. And the technical pitch is delivered by a pre-sales team whose job is winning the deal, not staffing it.
Worse, none of this touches the things that actually sink engagements. Bad partnerships rarely fail on raw competence. They fail on the stuff that only shows up after the contract is signed: who really does the work, what happens when someone leaves, how bad news travels, who owns the code, and whether the partner makes more money when you do or when you don’t. You can’t see any of that on the deck. You can only hear it in how a partner answers questions they’d rather you didn’t ask.
How to use this diagnostic
Ask these live, in a conversation, not as a questionnaire they can polish offline. You’re not grading whether they have an answer — a good firm has answers for everything. You’re reading two things: how specific the answer is, and how comfortable they are giving it. Vagueness, deflection, and rehearsed reassurance are the signals. A partner who gets concrete and a little candid is showing you how they’ll behave when things get hard.
One more thing, and it’s the honest part most vendors won’t write: ask these of us too. Ask them of every firm you’re considering, Kansoft included. A partner worth hiring is relieved you care this much. The one that flinches has just told you everything you need to know.
1. Who exactly will write our code, and can I interview and reject them?
The team in the room during sales is often not the team that ships. The most common way engagements go wrong is a quiet bait-and-switch: senior architects to win the deal, juniors to do the work.
Green flag — they name the actual engineers, offer interviews, and let you decline anyone without drama.
Red flag — ”our team is fully interchangeable; we assign by availability,” or any resistance to you meeting the people before you sign.
2. Show me a project that went sideways — what happened, and what did you change?
Every real partner has shipped a disaster. The useful signal isn’t whether they have one; it’s whether they’ll tell you, and what they did about it afterward.
Green flag — a specific story with their own mistakes included, and a concrete process change that came out of it.
Red flag — ”we’ve never had a project fail,” or a tidy tale in which the client was the only problem.
3. How do you estimate, and how often are you wrong?
Sales optimism is the seed of most blown timelines. You want a partner who estimates like an engineer, not like a closer.
Green flag — a described method, ranges rather than single numbers, and an honest hit rate (“we land within 20% about two-thirds of the time”).
Red flag — confident precision on work they’ve barely scoped, or no idea how often their estimates miss.
4. Who owns the IP, the code, and the infrastructure — on day one, or only at the end?
Some partners hold repositories, code, or cloud accounts as leverage until final payment or renewal. Ownership timing is the detail that bites.
Green flag — you own everything from the first commit; code lives in your repos and your cloud accounts.
Red flag — IP transfers “on completion,” code sits in their environment, or the contract goes quiet on the question.
5. Walk me through what leaving looks like — offboarding and knowledge transfer.
A partner confident in their work makes leaving straightforward. Lock-in by design is a tell, and you want to hear the exit plan before you need it.
Green flag — a real offboarding process — documentation, handover, transition support — described without hesitation.
Red flag — ”nobody’s ever left,” or an offboarding process that’s undefined or quietly punitive.
6. Can I see the real SLA and liability terms, not the brochure?
Accountability lives in the contract, not the pitch. What a partner is willing to be liable for tells you what they actually stand behind.
Green flag — clear SLAs, defined remedies when they’re missed, and willingness to share the actual master agreement early.
Red flag — SLAs that are all aspiration and no consequence, or “let’s not worry about the contract yet.”
Also read
Still upstream of this — not sure whether to partner at all, or which model fits? Settle that question first:
7. Whose process do we run — yours, ours, or a real blend? Give me a concrete example.
Some partners impose a rigid methodology; others have no spine and simply absorb your chaos. You want deliberate fit, not either extreme.
Green flag — a specific example of adapting to a client’s stack and rituals while holding their own quality guardrails.
Red flag — ”we have our proven process” with no give, or “we’ll do whatever you want” with no standards of their own.
8. What’s the time-zone overlap with the people doing the work, not the account manager?
A warm, overlapping account manager means nothing if the engineers are asleep while you’re working. The overlap that matters is with the delivery team.
Green flag — a concrete number of daily overlap hours with the engineers, and how they protect that window.
Red flag — overlap framed around the PM or account layer, or vague reassurance about “flexibility.”
9. How, and how fast, will you tell me bad news?
The gap between a recoverable slip and a full disaster is how early you hear about it. Cultures that hide bad news cost you the most, and they cost you late.
Green flag — a defined escalation path and an example of proactively raising a problem to a client.
Red flag — ”we solve problems before they ever reach you” — which usually means you find out when it’s too late to act.
There are a few questions competitors skip, because they’re uncomfortable. They’re also the most predictive.
10. How do you make money on this engagement, and where do your incentives diverge from mine?
Every pricing model misaligns somewhere: time-and-materials rewards more hours; fixed-bid rewards cutting corners. A partner who can name the misalignment is one you can actually manage.
Green flag — an honest account of where their model and your interests pull apart, and how they guard against it.
Red flag — ”our interests are perfectly aligned with yours.” No model is perfectly aligned; saying so is either naïve or a closing line.
11. What kind of client are you bad for?
A partner that fits everyone fits no one. The ability to name who they shouldn’t work with is a sign of self-knowledge and plain honesty.
Green flag — a clear, specific answer (“we’re wrong for pre-product startups that need a single generalist to figure it all out”).
Red flag — “we can help anyone,” or a non-answer dressed up as humility.
12. When we hit a hard disagreement, who wins — and how do you decide?
You will disagree about architecture, scope, or quality. How a partner handles being told no — and how they tell you no — defines the relationship more than any kickoff does.
Green flag — a described decision principle (reversible calls move fast, one-way-door calls escalate) and an example of pushing back on a client for the right reasons.
Red flag — pure deference (“the client is always right”), or rigidity that steamrolls your context.
Scoring what you heard
You’re not tallying correct answers. You’re reading specificity and comfort. A partner who’s a little vague on Questions 1–6 might still be fine. A partner who gets cagey on Questions 10–12 — money, fit, disagreement — has handed you the most important data point in the entire process. Treat evasion on any incentive question as close to disqualifying.
A rough rule: more than two red flags, or a single flag your gut won’t release, and you keep looking. The discomfort you feel asking about these is the same discomfort that, left unasked, becomes a six-month problem.
| The question to ask | Walk away if you hear |
|---|---|
| 1Who exactly will write our code, and can I interview and reject them? | ⚑“Fully interchangeable team,” no interviews |
| 2Show me a project that went sideways — what happened and what did you change? | ⚑“We’ve never had one” |
| 3How do you estimate, and how often are you wrong? | ⚑Confident precision on unscoped work |
| 4Who owns the IP, code, and infrastructure — day one, or only at the end? | ⚑“Transfers on completion” |
| 5Walk me through what leaving you looks like — offboarding and knowledge transfer. | ⚑No offboarding process |
| 6Can I see the real SLA and liability terms, not the brochure? | ⚑SLAs with no consequences |
| 7Whose process do we run — yours, ours, or a real blend? | ⚑No flexibility, or no standards |
| 8What’s the time-zone overlap with the people doing the work, not the account manager? | ⚑Overlap framed around the PM |
| 9How, and how fast, will you tell me bad news? | ⚑“Problems never reach you” |
| 10How do you make money here, and where do your incentives diverge from mine? | ⚑“Perfectly aligned with yours” |
| 11What kind of client are you bad for? | ⚑“We can help anyone” |
| 12When we hit a hard disagreement, who wins, and how do you decide? | ⚑“The client is always right” |
Evasion on the incentive questions (10–12) is the strongest signal of all. More than two red flags — or a single one your gut won’t release — and you keep looking.
What a good partner does when you ask
Here’s the part most firms won’t print. A good partner wants you to ask about these things. Ask who writes the code and a confident one is glad you care. Ask how they make money and an honest one respects you more for it. These questions only threaten a partner who was counting on you not asking them.
So, ask all twelve — of us, and of everyone on your shortlist. The firm that answers with specifics and a little candor is the one worth a deeper look. The one that flinches has already given you your answer.
Got any questions to ask our team?
We'd love to answer them now rather than wait for later.
