What questions should I ask a software development company before hiring them?

Start with ownership and exit: who holds the intellectual property and from when, whose account the repository lives in, and what you keep if you stop at month two. Then ask for an estimate they got wrong and what would make them tell you not to build. Those five separate partners from vendors faster than any technical question.

How do I compare quotes from different development agencies?

By comparing their exclusion lists, not their totals. Two quotes for the same brief regularly differ by a factor of two because one assumed working APIs and unmigrated data while the other checked. Without the exclusions, the numbers are not comparable.

What are the warning signs when choosing a development partner?

Four answers should end the conversation: no discovery needed, IP transfers on final payment, never missed an estimate, and team assigned after signature. Each has a specific and predictable consequence later in the engagement.

Should the development team or my company own the repository?

Yours, with their engineers invited to it, from the first commit. If the repository lives in the vendor account and is transferred at the end, the transfer becomes the moment of maximum leverage — and it arrives exactly when disagreements are most likely.

Is a portfolio a good way to evaluate a software company?

Only weakly. A portfolio shows work done under budgets, deadlines and data quality you cannot see, with teams that may no longer exist. Answers about failure, ownership and staffing are harder to fake and predict your outcome better.

How important is time zone overlap when choosing a partner?

It matters in proportion to how often your work blocks on a decision. Ask for the overlap in hours and what they do about the hours that do not overlap; an answer of "we are flexible" means somebody will work nights and nobody has decided who.

Guide

How to choose a software development partner

Published 2026-08-14 · Updated 2026-08-14

Portfolios and case studies tell you what a company did with someone else’s constraints. What predicts your outcome is how they answer questions about failure, ownership and staffing — so this guide is twelve questions, what a good answer sounds like, and the four that should end the conversation.

Why portfolios predict so little

A portfolio shows finished work under conditions you cannot see: the budget, the deadline, how good the client’s data was, and whether the team that built it still exists. None of those transfer to your project.

The questions below are chosen for a different property — they are hard to answer well without actually working the way the answer describes. A company can show you screenshots of anything. It cannot invent a coherent answer to what happens when a build slips.

The twelve questions

Ask them in a call, not by email. What you are listening for is whether the answer is specific or rehearsed.

01
Who owns the intellectual property, and from when?
Good answer: the client, from the first commit, written into the contract. Vague answers about "on final payment" mean the code is leverage until then.
02
Whose account does the repository live in during the work?
Good answer: yours, with their team invited. This is the single most skipped question and the one that decides who holds the work if the relationship breaks.
03
What happens if we stop the project at month two?
Good answer: a named notice period, and you keep everything built so far in a state you can hand to someone else. Anything that leaves you with an unrunnable half-system is a trap.
04
Show me an estimate you got wrong.
Good answer: a specific one, what caused it, and what changed afterwards. A company that has never been wrong has not shipped much or is not being straight with you.
05
Which integrations have you assumed are documented?
Good answer: a list, with the ones they have verified marked separately from the ones they have assumed. Integrations are the largest cost driver and the most common source of overrun.
06
Is data migration inside or outside the number?
Good answer: explicitly one or the other. Ambiguity here is either a hidden large number or evidence nobody looked at your data.
07
How fast do you need us to answer questions?
Good answer: a specific target, usually one working day, and a stated consequence when it slips. A partner who does not ask this has not noticed that client latency drives their timeline.
08
What is excluded from the estimate?
Good answer: a written list. The absence of an exclusions list means the estimate has not been thought about, because every real estimate has boundaries somebody chose.
09
Who is on this project in month three, by name?
Good answer: the same people you are talking to, or an honest description of who rotates and when. Selling with seniors and staffing with juniors is the oldest pattern in this industry.
10
How many hours a day do our teams overlap?
Good answer: a number, and what they do about the hours that do not. "We are flexible" means someone is going to work nights and nobody has decided who.
11
What does handover look like if we bring this in-house?
Good answer: documentation and access as an ongoing practice, not an event at the end. A partner who treats handover as a threat has an incentive to keep you dependent.
12
What would make you tell us not to build this?
Good answer: concrete cases — an existing product covers it, volume is too low, the data does not exist yet. A partner who cannot describe a situation where they would decline is selling hours, not outcomes.

Four answers that should end the conversation

Not warning signs to weigh against the rest. Each of these has a specific consequence you will meet later.

What you hear	What it means later
"We can start Monday, no discovery needed."	Scope is undefined, so every disagreement becomes a change order
"IP transfers on final payment."	The code is leverage in any dispute, including one about the code
"We have never missed an estimate."	Either untrue, or they have only done work small enough not to count
"The team is assigned after signature."	You are buying capacity, not people, and cannot evaluate what you get

What to do with the answers

Score partners on questions 1, 2, 3 and 12 first. Those four cover ownership, exit and honesty, and a partner who fails any of them will not be redeemed by a strong technical answer elsewhere.

Then compare estimates only against their exclusion lists. Two numbers for the same brief are not comparable until you know what each one assumed about integrations and data — that difference alone routinely explains a factor of two.

And treat the discovery stage as part of the evaluation, not as a formality before the real work. It is the cheapest opportunity you will have to find out how a partner behaves when something turns out harder than expected.

Common questions

What questions should I ask a software development company before hiring them?: Start with ownership and exit: who holds the intellectual property and from when, whose account the repository lives in, and what you keep if you stop at month two. Then ask for an estimate they got wrong and what would make them tell you not to build. Those five separate partners from vendors faster than any technical question.
How do I compare quotes from different development agencies?: By comparing their exclusion lists, not their totals. Two quotes for the same brief regularly differ by a factor of two because one assumed working APIs and unmigrated data while the other checked. Without the exclusions, the numbers are not comparable.
What are the warning signs when choosing a development partner?: Four answers should end the conversation: no discovery needed, IP transfers on final payment, never missed an estimate, and team assigned after signature. Each has a specific and predictable consequence later in the engagement.
Should the development team or my company own the repository?: Yours, with their engineers invited to it, from the first commit. If the repository lives in the vendor account and is transferred at the end, the transfer becomes the moment of maximum leverage — and it arrives exactly when disagreements are most likely.
Is a portfolio a good way to evaluate a software company?: Only weakly. A portfolio shows work done under budgets, deadlines and data quality you cannot see, with teams that may no longer exist. Answers about failure, ownership and staffing are harder to fake and predict your outcome better.
How important is time zone overlap when choosing a partner?: It matters in proportion to how often your work blocks on a decision. Ask for the overlap in hours and what they do about the hours that do not overlap; an answer of "we are flexible" means somebody will work nights and nobody has decided who.

Ask us the twelve

These are the questions we would want a client to ask us, including the uncomfortable ones. Bring them to a call and see how the answers sound.

Start a conversation

Related guides

Nearshore vs offshore software development
Overlapping hours, real cost after coordination, IP jurisdiction and travel, compared dimension by dimension — including when offshore is the better call.
What custom software development costs
The five drivers that move the number, a worked estimate you can run on your own project, and the questions that change a quote.
Custom software vs off-the-shelf
A decision frame by time horizon and total cost of ownership, plus the signals that say you chose wrong and it is time to switch back.