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 it is 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, together 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 moves from a call to a quote to code has skipped the stage where the wrong product gets caught.

2. How do you decide what goes into the first version? A good answer is that scope is decided with you, in writing, with a reason recorded next to every cut. A reply that they simply build what is in the specification should give you pause.

3. How often will I see working software? The answer should be every couple of weeks at most, as a demo you can click through rather than a report. If the first demo is scheduled for the end of the project, look elsewhere.

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 claims to need nothing because it handles 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 the answer is 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 the practice depends on who is busy.

12. What is tested automatically, and what happens when a test fails? The right answer is automated tests on every change, in a pipeline that blocks whatever fails. Testing only at the end is a warning.

13. How do you deploy, and how do you know when something breaks in production? The answer should cover separate environments, deployments that do not take the product down, and monitoring that alerts them before it alerts you.

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? The answer should cover 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 and the first month after launch have each been treated as an 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 cloud, app store and domain accounts 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, whether through a retainer, hourly work or 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 that 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 wish. A sheet with the questions down the side and the vendors across the top is enough to compare several. The pattern matters more than the points, however. Plain, specific answers that name people, tools and steps are the signal. Confident generalities are the noise.

Then check references, and start small where you can, with 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.