How to choose a software development partner: 10 questions to ask
Choosing who builds your software is the highest-stakes decision in the project, and it is made before a single line of code exists. You are buying judgement you cannot inspect, over months you cannot fast-forward. The ten questions below are the ones whose answers actually separate studios — not because the questions are clever, but because a weak partner cannot answer them well without lying, and lies about process are easy to catch.
How they work
1. What does your process look like, week to week?
What you are really asking: will I know where this stands without chasing you? A studio with a real process describes it in concrete nouns — a demo at the end of each stage, a written scope before build, a tracker you can see.
A good answer sounds like: “Discovery is one to three weeks and ends with an architecture and a costed plan you approve. Then design, then build in iterations with a working demo every two weeks.”
A weak answer sounds like: “We’re agile, we’ll keep you in the loop.” Agile is a family of practices, not a process. Ask which ones.
2. How often will we communicate, and through what?
The failure mode here is not too little contact — it is unpredictable contact. Weekly written updates you can forward to your own stakeholders beat daily calls that leave no record. Ask specifically: who is my point of contact, are they technical, and what happens when they are on leave?
3. Who owns the code and the IP?
The answer must be you, and it must be in the contract rather than in an email. Ask three follow-ups that separate a real answer from a reassuring one: whose name are the cloud accounts in, when does the repository transfer, and do you reuse any of this code for other clients? A studio that has thought about ownership answers all three immediately.
4. How do you handle scope changes?
Every real project changes. What matters is whether the studio has a mechanism — a written change note, a re-estimate, your approval — or whether changes are absorbed silently until the timeline slips and nobody can say when it started slipping. Beware both extremes: a partner who bills for every clarification, and one who says “don’t worry, we’ll fit it in,” which is how projects quietly run three months late.
The work itself
5. Can we see something you built that is still running?
Live software beats a slide deck, and software still running two years later beats software launched last month. If client work is under NDA — which is normal — a studio should be able to walk you through the architecture verbally, show its own products, or arrange a reference call. What should worry you is a portfolio of launches with nothing you can visit today.
6. How do you know the software works?
Listen for mechanisms, not adjectives. “We’re careful” is not a quality process. “Every change goes through review, and the test suite runs against a real database rather than an in-memory substitute” is. Ask what broke on their last project and how they found out — a studio that answers honestly has a real feedback loop; one that claims nothing has ever broken is either new or not telling you the truth.
7. What happens when the traffic or the data grows tenfold?
You are not asking them to build for a scale you do not have. You are checking that they know which decisions are expensive to reverse. Database schema, tenancy model and how money is stored are hard to change later; a button colour is not. A good partner can tell you which of your decisions are one-way doors.
8. What happens after launch?
Ask for the shape of the arrangement, not just the promise. Is support a retainer, an hourly rate, or best-effort? What is the response time when something breaks at 2am? Who holds the pager? Software that nobody is responsible for after go-live degrades quietly for months before anyone notices.
The relationship
9. Who exactly will write this?
This is the question most likely to expose a mismatch between who sells and who delivers. Ask for names, seniority and how many other projects those people are on simultaneously. If the answer is that the team is assigned after signing, you are buying availability, not expertise.
10. What do you need from us to make this succeed?
The best answer is uncomfortable. A partner who has delivered real projects will tell you they need a decision-maker who can be reached, access to the people who actually do the work being automated, and honesty about deadlines that are real versus aspirational. A studio that says it needs nothing from you has either not thought about it or is planning to build in the dark and hand you something at the end.
Reading the answers
| Signal | Encouraging | Concerning |
|---|---|---|
| Process | Named stages with defined outputs | “We’re flexible” |
| Estimates | A written number after scoping | A number on the first call |
| Ownership | In the contract, accounts in your name | “Of course it’s yours” and nothing written |
| Team | Named people you have met | Assigned after signature |
| Failure | A specific story with what changed | “Nothing has gone wrong” |
A quote produced before anyone understands your scope is not a price. It is a guess you will pay for later, either in change requests or in corners cut to protect the margin.
- Specificity is the signal. Weak partners give answers that could apply to any project.
- Get ownership, accounts and IP in the contract, not in conversation.
- Meet the people who will write the code, not only the people who sell it.
- Ask what broke last time. The answer tells you whether they have a real feedback loop.
- Treat a firm price offered before scoping as a warning, not a convenience.
The takeaway
The right partner is specific about process, puts ownership in writing, introduces you to the people who will build the thing, and is honest about what they need from you. If a studio dodges these questions in a sales conversation — when they are trying their hardest to impress you — that is the most cooperative they will ever be.
We would answer all ten of these for you on a call, including the uncomfortable ones. Start a conversation, or read the standards we hold our own systems to.