August 2026 · 3 min read
How to choose a development partner
What to ask before signing, what the answers tell you, and the four questions that separate a partner from a vendor.
ZitDevs engineering
Most companies choose a development partner the way they choose a supplier: three quotes, a comparison of prices, a decision. That works when the thing being bought is the same in every quote. Software is not that thing. Two teams can quote the same feature list at the same price and hand back work that differs by years of maintenance cost.
What follows is what to ask instead.
Ask who will actually do the work
The people in the sales meeting are frequently not the people who write the code. That is not dishonest by itself — a sales engineer who can scope work is doing a real job. It becomes a problem when nobody will tell you who takes over afterwards.
Ask directly:
- Who writes the code, by name and role?
- Are they employees, subcontractors, or a mix?
- What happens when one of them leaves mid-project?
A partner who cannot answer the third question has not thought about it, which means you will be the one who discovers the answer.
Ask what happens when the estimate is wrong
Every estimate is wrong. The question is what the contract does about it.
A fixed-price contract moves the risk to the partner, which sounds good until you realise what it buys them: an incentive to argue that everything you ask for is out of scope. Time and materials moves the risk to you, which sounds bad until you realise it buys you the ability to change your mind without a negotiation.
Neither is the right answer in general. The right answer is the one where both sides can say out loud what they do when the estimate breaks.
If a partner tells you their estimates do not break, you have learned something about the estimates.
Ask to see the handover
This is the question that separates a partner from a vendor, and almost nobody asks it.
Ask what you receive at the end. Not the running application — the repository, the deployment pipeline, the credentials, the documentation, the decision record. Ask whether another team could pick it up without calling them.
A partner who has built for handover will show you a previous one. A vendor who has built for lock-in will explain why the question does not apply.
Ask what they will refuse to do
A partner who agrees with everything is not evaluating your idea. They are quoting it.
The most useful thing a technology partner does in the first month is tell you which part of your plan is expensive for a reason you had not considered — and which part you can drop entirely. That conversation is worth more than the discount you were negotiating.
If you are running this evaluation now and want a second opinion on the answers you are getting, a consultation covers exactly that. No pitch attached.