9 Questions to Ask a Software Development Company Before You Sign Anything
The worst software projects we have been asked to rescue did not fail because of bad code. They failed because of a conversation that never happened.
Someone signed a proposal that looked professional, from a company that presented well, and six months later they had a repository they could not read, a team they could not reach, and no idea which of the two was the bigger problem.
The questions to ask a software development company are not technical. You do not need to understand their stack. You need to understand how they work, who actually does the work, and what happens when things go wrong — because on a project of any length, something will.
Here are the nine we would ask if we were on the buying side, with what a good answer sounds like and what should make you pause.
1. Who will actually write my code, and can I meet them?
This is the single most useful question, and it is the one most likely to produce squirming.
A common pattern in this industry is that senior people sell the work and junior people do it. That is not automatically bad — juniors supervised properly produce good software — but you are entitled to know the shape of the team before you commit.
A good answer names roles and seniority, tells you who leads technically, and offers you a conversation with that person. Not a sales engineer. The person who will make architectural decisions.
A red flag is vagueness about team composition, or a refusal to let you speak to anyone who is not in sales. If the people you meet during the pitch vanish after signing, you were sold a different product than you bought.
2. Who owns the code, the repository, and the intellectual property?
The answer should be: you do, from the first commit, unconditionally.
A good answer is immediate and unambiguous, and the contract says it plainly. You should have your own repository, under your own account, with your own administrative access, from day one.
A red flag is code held in the vendor's account and transferred "at project completion", or any licensing arrangement where components they wrote for you remain theirs. That arrangement exists to make leaving expensive. Also check who owns the design files, the infrastructure accounts, and the domain — we have seen all three used as leverage.
3. What does your testing actually consist of?
Every company says they test. The word covers everything from rigorous automated coverage to one person clicking around before a release.
A good answer is specific and slightly boring: what is covered automatically, what is checked by hand, whether tests run on every change, and what their policy is when a test fails. They should be comfortable saying which parts are not tested and why.
A red flag is "we have a QA process" with no detail, or the claim that everything is fully tested, which is never true and suggests either inexperience or salesmanship.
If the product handles payments, personal data or logins, ask specifically what they do about security. A partner who cannot reference something like the OWASP Application Security Verification Standard is unlikely to have a systematic approach to it.
4. How will I see progress between now and delivery?
Long gaps between updates are where projects quietly go wrong. You want to see working software regularly, not status percentages in a spreadsheet.
A good answer describes a rhythm: a demonstrable environment you can open yourself, updated on a predictable cadence, plus a regular call where you see what changed. Two weeks is a reasonable maximum gap.
A red flag is a plan where you see nothing substantial for months, or where "progress" is reported as a number rather than shown as a thing that runs.
5. What happens when I want to change something mid-project?
You will change your mind. Everyone does, because you learn things once you see the product working. The question is whether the process handles that gracefully or punitively.
A good answer explains a specific mechanism: how a change gets estimated, who approves it, and how it affects timeline and cost. They should be relaxed about it, because they have done it many times.
A red flag is either extreme. A company that says any change is fine at no cost is either padding heavily or will resent you later. A company that treats every change as a contractual incident will make the project miserable.
6. What does handover look like if we stop working together?
Ask this even if you have no intention of leaving. The answer tells you a great deal about how they think about the relationship.
A good answer describes documentation, a walkthrough, credentials transfer, and a defined handover period. Some will have done it before and can describe it concretely.
A red flag is discomfort with the question, or an answer implying the system is too complex for anyone else to maintain. That complexity is often manufactured, and it is the most common form of lock-in in this industry.
7. Can I talk to a client whose project went badly?
Everyone provides references. References are curated.
A good answer is a genuine one: a project that overran, or scope that got cut, and an honest account of why and what they did about it. Every company that has been operating for a few years has these. Willingness to discuss one is a strong signal of honesty.
A red flag is the claim that nothing has ever gone wrong. That is not a track record, it is a sales script.
If any of this feels hard to judge
You are being asked to evaluate technical competence without being technical, which is genuinely difficult and not a failing on your part.
If you would like a second opinion on a proposal you have received — even one from someone else — we are happy to read it with you. We would rather you hire the right partner than the wrong one, and sometimes the right answer is not us.
8. What are you assuming that is not in this proposal?
This question is unusual enough that the reaction alone is informative.
Every estimate rests on assumptions: that you will provide content by a certain date, that a third-party integration works as documented, that you have someone available to answer questions, that the design will not change fundamentally after approval.
A good answer produces a list, ideally one already written down. Good teams track their assumptions because unstated assumptions are where estimates go to die.
A red flag is "nothing, it is all covered." No estimate is assumption-free. That answer means either they have not thought about it, or they have and would prefer you did not.
9. What would you remove from this project if it were yours?
The last question, and the most revealing.
A good answer is an actual opinion. A partner who has built products has views about what matters and what is decoration, and should be willing to tell you that three of your twelve launch features could wait. That advice is worth more than the discount you were negotiating.
A red flag is enthusiastic agreement with everything. A vendor who accepts your scope without challenge is optimising for signing the contract, not for your product succeeding. You want someone who will argue with you occasionally.
What to do with the answers
Do not score these like an exam. Read them for a pattern.
The companies worth working with tend to be specific where it matters, comfortable admitting limits, and willing to disagree with you. The ones to avoid tend to be smooth on everything, vague on team and ownership, and agreeable about scope.
Two practical suggestions. Ask the same nine questions to every company you are considering, so you are comparing like with like. And write the answers down — not for the contract, but so you can check in three months whether what you were told matches what is happening.
The questions to ask a software development company, in one list
If you take nothing else from this, take the list itself. Print it, bring it to the call, and work through it in order:
- Who writes my code, and can I meet them?
- Who owns the code, the accounts and the intellectual property?
- What does your testing actually consist of?
- How will I see working software between now and delivery?
- What happens when I want to change something mid-project?
- What does handover look like if we part ways?
- Can I speak to a client whose project went badly?
- What is this proposal assuming that it does not say?
- What would you cut if this were your product?
None of these require you to be technical. All of them are hard to answer smoothly if the underlying practice is not there. That asymmetry is the entire point.
One more suggestion, borrowed from a different industry: ask the same question twice, weeks apart, to two different people at the company. Consistent answers mean the practice is real. Different answers mean you were told what someone thought you wanted to hear. Contract lawyers call this the tell, and it works just as well for software as it does anywhere else. The Standish Group's long-running research on project outcomes has consistently pointed at communication and clarity, rather than technology, as what separates projects that land from projects that do not.
Price is the last question, not the first
We have deliberately left cost out of the nine. It matters, but it is the easiest thing to compare and the least predictive of outcome. A cheaper partner who delivers nothing is infinitely more expensive than a pricier one who ships.
For what it is worth, our own ranges sit well below typical North American and Western European agency pricing — a lean product build runs $8,000 to $18,000 and a standard one $18,000 to $40,000 — because of how our team is structured, not because of shortcuts. But we would still rather you asked the other nine questions first, of us and of everyone else.
If you are evaluating partners for a build and want a conversation that starts with scope rather than a quote, book a free consultation call or email nitheesh@playxoft.com. Bring the nine questions. We are happy to be measured against them.
