Knowing how to choose the right custom software development partner matters more than the brief you hand them. A good brief given to the wrong team produces an expensive disappointment. A vague brief given to the right team usually gets interrogated until it becomes a good brief.
Most selection processes test the wrong things. They compare day rates, count years in business, and ask for case studies from the same industry. None of those predict much. What follows are the questions that do.
Ask what they would remove from your scope
This is the single most useful question in a first conversation, and almost nobody asks it.
A partner who answers “nothing, we can build all of it” is telling you they intend to bill for all of it. A partner who has actually read your brief will name two or three things that are expensive relative to the value they carry, and will explain why the first release is stronger without them.
You are not looking for someone who shrinks the project. You are looking for evidence that they can distinguish between what you asked for and what you need — because you will rely on that judgement every week once the build starts.
Ask who writes the code, and where they sit
The people in the pitch are frequently not the people on the keyboard. That is not automatically a problem, but the gap should be stated rather than discovered in month two.
Worth establishing directly:
- Which named people will be on your project, and at what percentage of their week.
- Whether the team is employed or subcontracted, and if subcontracted, by whom.
- What the timezone overlap actually is — not the office locations, the hours of genuine overlap.
- Who you speak to when something breaks at 4pm on a Friday.
Distributed delivery works well when the handover is designed. It fails when it is accidental. The question is not whether a team is distributed but whether they can describe their handover without improvising.
Ask to see something that went wrong
Every portfolio is a highlight reel. The useful question is what happened on the project that did not go to plan — and the answer tells you more than any case study.
Listen for whether they describe a system failure or a blame story. “The client kept changing their mind” is a blame story, and it predicts how they will describe you to their next prospect. “We committed to an integration before we had access to the sandbox, and we lost five weeks” is a system failure, and it usually comes with a description of what they changed afterwards.
Ask what happens to the code if you leave
Ownership, hosting and handover should be settled before the contract, not at the end of it. The specifics to pin down:
- Who owns the intellectual property on delivery, in writing.
- Whose cloud accounts the infrastructure runs in — yours or theirs.
- Whether the repository is accessible to you throughout, or delivered at the end.
- What documentation exists, and whether another team could pick it up.
A partner who is comfortable with all four is confident you will stay for reasons other than lock-in. A partner who gets vague here is telling you something important.
Ask how they price change
Requirements change on every project worth doing. The question is whether the commercial model treats that as normal or as a dispute.
Fixed-price contracts price change as a variation, which sets up an adversarial conversation every time you learn something. Time-and-materials prices change as ordinary work, but offers no ceiling. Neither is wrong; what matters is that the model matches how much genuine uncertainty the project carries.
A build where the rules are well understood — a known integration, a familiar workflow — can carry a fixed price safely. A build where the requirements will be discovered in contact with real users cannot, and anyone who quotes a firm number for it is either padding heavily or planning to argue later.
The answers that should worry you
Three responses that sound reassuring and are not:
“We can start Monday.” Capacity that immediate usually means someone else just left, or the team assigned to you is the team nobody else wanted.
“We’ve built exactly this before.” Rarely true, and if it were, you would be buying a product rather than commissioning a build. What you want is a team that has solved a structurally similar problem and can explain how yours differs.
“We’ll follow your specification exactly.” Compliance is not a virtue in a partner whose job includes telling you when the specification is wrong.
What good looks like in the first month
You can tell within four weeks. A partner who is working out well will have narrowed the scope at least once, surfaced a problem you had not seen, shown you something running rather than something designed, and told you at least one thing you did not want to hear.
If month one has been entirely agreeable, that is not a good sign. It usually means nobody has looked hard enough at the difficult parts yet, and those parts are still ahead of you.
We build custom software for companies across the United States, Saudi Arabia and Africa, with delivery engineering in Islamabad. If you are working through this decision, tell us what you are building — describing the problem is more useful than specifying the solution. Worth settling early too: how much timezone overlap you actually need.
Common questions
What should I ask a software development partner first?
What they would remove from your scope. A partner who says they can build all of it intends to bill for all of it. One who has read the brief will name things that cost more than they are worth and explain why the first release is stronger without them.
How do I check who will actually do the work?
Ask for named people, their percentage allocation, whether they are employed or subcontracted, and how many hours of genuine timezone overlap exist. The people in the pitch are frequently not the people on the keyboard.
What are the warning signs?
"We can start Monday" usually means someone just left. "We have built exactly this before" is rarely true. "We will follow your specification exactly" is not a virtue in someone whose job includes telling you when the specification is wrong.
