Choosing a software house is a decision for months, sometimes years. A bad choice does not only cause delays - it often means rewriting the product and losing customer trust. The good news: most problems can be spotted during the first conversations.
Here are 12 questions to ask every potential partner. Not to test them, but to see how they think and whether they speak plainly.
1. Who will be my main contact?
You want to talk to someone who makes decisions and knows the project. If the contact is purely sales and the team “will appear later”, the risk of misunderstanding grows.
2. Who actually writes the code?
Ask whether the project will be handled in-house or subcontracted. This affects quality control, communication and accountability.
3. What does the process look like, and when will I see progress?
A good process has stages, demos and acceptance points. If all you hear is “we will stay in touch”, that is not enough.
4. How do you define scope and changes?
Scope should be written down, and changes should have a clear procedure. This protects both sides from an endless “it is just a small thing”.
5. Is the quote fixed?
A fixed quote is possible when the scope is clear. If the price is “estimated”, ask what happens if the project runs late and who carries the risk.
6. What happens when a problem appears?
Every project has problems. What matters is how the partner talks about them: do they inform early, propose solutions and take responsibility, or look for someone to blame?
7. Who owns the code?
The code should be yours. Ask about the repository, licences, access and handover terms. Vendor lock-in is a risk, not a business model.
8. How do you handle security?
This is not a “technical extra”. If the answer is “we have hosting with an SSL certificate”, it is not enough. Ask about authentication, permissions, dependencies and audits.
9. What does documentation and handover look like?
A good partner can describe the project so another team can take it over. That is a maturity test, not a lack of loyalty.
10. What happens after launch?
Define what support includes, how long it lasts and what it costs. “We will be available” is not an SLA.
11. Can I talk to a client?
References are valuable when you can ask someone who actually worked with the team. If the partner avoids this - consider why.
12. What should we not build?
This is the best question to end with. A good partner will tell you which features are unnecessary, risky or premature. If everything is “a great idea”, they are not advising - they are selling.
Warning signs
- A quote without scope and without questions about the product.
- Pressure for a quick decision and an “offer that expires today”.
- No clear answer about code ownership.
- Avoiding the topics of security and documentation.
- A portfolio with no way to contact clients.
- Promising “everything” in an unrealistic timeframe.
Summary
Do not look for the cheapest or fastest partner. Look for one who understands your goal, speaks plainly about risks and can explain technical decisions in simple language. The rest - price and timeline - follows from a good conversation.
Want to ask these questions in practice? Book a free consultation - I will answer each of them without beating around the bush.