25 questions to ask a software development company before you sign

Why the questions matter more than the pitch

Every software development company will tell you they are experienced, agile and client-focused. The pitch is the same everywhere, so it tells you almost nothing. What separates a good partner from an expensive mistake is how they answer specific questions about how the work actually happens. Here are the 25 we would want a founder to ask us, grouped by what they reveal, with the answers that should make you comfortable and the ones that should make you cautious.

About their process

1. What happens between our first call and the first line of code? You want to hear about discovery, scope and a prototype. A company that goes from a call to a quote to code has skipped the part where the wrong product gets caught.

2. How do you decide what goes into the first version? Good answer: with you, in writing, with a reason next to every cut. Red flag: "we build what is in the specification."

3. How often will I see working software? Every couple of weeks at most, as a demo you can click through, not a report. If the first demo is at the end, walk away.

4. How do you handle a change of scope mid-project? There should be a process, and it should not be a fight. The answer tells you whether change is expected or punished.

5. What do you need from me, and how much of my time? A partner that needs a decision from you most days will say so. One that says "nothing, we handle everything" is not planning to involve you.

About the people doing the work

6. Who exactly will work on my product, and can I talk to them? The people on the sales call and the people on the project are often not the same. Ask to meet the ones who will build it.

7. Will the team change during the project? Rotation is normal in large companies and costly for you. Ask how continuity is protected.

8. Do you build the product yourselves, or subcontract parts of it? Neither answer is wrong, but you should know.

9. Who owns the product decisions on your side when I am not available? If nobody, expect silence between your check-ins.

10. Have you built something like this before, and can I see it? Relevant experience beats general experience. Ask for the closest case, not the most impressive one.

About engineering quality

11. How does code get reviewed before it ships? The answer you want is that a second engineer reviews every change. Anything vaguer means it depends on who is busy.

12. What is tested automatically, and what happens when a test fails? Automated tests on every change, in a pipeline that blocks what fails. "We test at the end" is a warning.

13. How do you deploy, and how do you know when something breaks in production? Separate environments, deployments that do not take the product down, and monitoring that tells them before you do.

14. Which technologies would you use for my product, and why those? Listen for a reason tied to your product rather than to their habits.

15. What does a handover look like if we ever take the product in-house? Documentation, clean repositories, and infrastructure in your own accounts. If they cannot describe it, it will be painful.

About money and contracts

16. Fixed price or time and materials, and why for this project? A good partner recommends one based on how well the scope is known, and can explain the trade-off.

17. What is included in the price, and what is not? Design, testing, deployment, app store submission, the first month after launch: each of these has been "extra" somewhere.

18. What happens to the budget if we cut scope? In a fixed-price contract, ask whether savings come back. In time and materials, ask how spending is reported.

19. Who owns the code, the designs and the accounts? The answer should be you, and the accounts (cloud, app stores, domains) should be in your name from day one.

20. How do you handle confidentiality? A plain answer about an NDA and access controls is enough. Evasiveness is not.

About after launch

21. What happens in the first month after launch? Someone should be watching, fixing and adjusting. Ask who, and at what cost.

22. How do you support the product later: retainer, hourly, on request? Know the options before you need them.

23. What will it cost to add a feature six months from now? The honest answer is a way of estimating, not a number. The dishonest answer is "it depends" with nothing after it.

24. If we outgrow you, how do we leave? A company confident in its work will describe an orderly exit.

25. What would you do differently on your last project? A partner who cannot name anything has not been looking.

What to do with the answers

Score them if you like; a sheet with the questions down the side and the vendors across the top is enough to compare several. But the pattern matters more than the points. Plain, specific answers that name people, tools and steps are the signal. Confident generalities are the noise.

Then check references, and start small if you can: a scoped first engagement, a prototype or a first version, before committing to a long one. How a company behaves in the first two weeks tells you more than any proposal.

If you are choosing a partner for a first version or for custom software development, ask us the same 25. We would rather answer them on the first call than have you find out later.