How to Choose a Software Development Company: 20 Questions
The wrong software vendor is a project's most expensive mistake, and it can usually be spotted in the first meeting. Twenty questions in five groups — experience, process, technical approach, contract, post-delivery — with what a good answer looks like and which answers are red flags.
The wrong software vendor is a project's most expensive mistake: the difference shows up not on the first invoice but in the release that isn't delivered in month six, or in the code nobody can touch in year three. The good news is that this mistake can usually be spotted in the first two meetings — if the right questions are asked. The 20 questions below, in five groups, are a checklist for every vendor conversation; for each one we wrote what a good answer looks like and which answer is a red flag.
Experience and references
Which projects have you done with a scope and industry similar to ours? A good answer is concrete: industry, user count, integrated systems, duration. Red flag: having done "everything" in every industry and being unable to give a single concrete example.
Can we speak to a reference from one of those projects? Good answer: a phone call with at least one customer. Avoiding references, or offering only written reference letters, deserves attention.
Have you had a project go badly, and what did you learn? Every experienced company has one. "Never" is not honest; a company that can describe what it learned shows maturity.
Who will actually work on the project — the same people as in the sales meeting? Good answer: developers and analysts by name and experience. Red flag: "we assign the team at kickoff", or the sales team disappearing after signing.
Process and communication
How do you start a project; is there a discovery and specification phase? Good answer: a written discovery output, approved scope, a prototype. Red flag: a firm price and date in the first meeting.
How will we see progress? Good answer: a working-software demo and a written status report at the end of every two- or three-week sprint. Red flag: "we deliver at the end" — six months of invisibility.
Who is our single point of contact, and how fast do we get answers? Good answer: a named project manager and a response-time commitment. An unclear contact costs the most time in the middle of a project.
What is the process when we request a scope change? Good answer: written change request, impact analysis (time/cost), implementation after approval. "We'll handle it" turns into an invoice later, or drags the project.
Technical approach
Which technologies do you recommend, and why? A good answer is justified and tied to your needs: team experience, long-term support, availability of developers in the market. Red flag: recommending one technology for every problem.
How do you write tests; is there automated testing? Good answer: unit and integration tests, a suite that runs in CI on every change. "Our test team tests manually" is not enough on its own.
How do you build the integration with our existing systems (ERP, accounting)? Good answer: they ask for the API documentation, data direction and failure scenarios. Red flag: postponing integration with "we'll look at that later".
How do you handle security and data protection? Good answer: role-based authorization, access logs, a personal-data inventory, a penetration-test recommendation. A company that can't answer this concretely should not work with enterprise data.
Contract and ownership
Who owns the source code, and when is it handed over? Good answer: the code belongs to the client, with access to the version-control repository from the start. Red flag: the code staying with the vendor, or an "as long as maintenance continues" condition.
How many person-days is the proposal based on, and on what assumptions? Good answer: a person-day breakdown and an assumption list. A single-number proposal cannot be compared.
Do you propose fixed price or time and materials, and why? A good answer depends on scope clarity and is justified; a hybrid (fixed-price discovery, sprint-based development) is a common and reasonable proposal.
How will acceptance criteria be defined? Good answer: a testable criterion for every requirement in the specification, acceptance testing done together. "We'll fix it until you like it" is well-meant but undefined.
After delivery
What is the warranty period and its scope? Good answer: free bug fixing for a defined period after delivery (typically 3–6 months); the scope is written down.
What does the maintenance and support contract cover, and what are the response times? Good answer: response and resolution times by priority level, a monthly maintenance scope (security patches, library updates). A vendor without a maintenance offer leaves the software ownerless.
Are documentation and handover training part of the delivery? Good answer: technical documentation, an installation guide, recorded user training. Without these, another team cannot take over.
What happens if we part ways? A good answer is calm and clear: code, data and documentation are yours; a reasonable handover process. A vendor uncomfortable with this question has made dependency its business model.
A scoring suggestion
Give each question 0–2 points (0: no answer or red flag, 1: partial, 2: concrete and satisfactory). Don't shortlist a vendor scoring below 30 out of 40, whatever the price. The lowest bid and the highest score rarely meet in the same company; the questions that usually decide it are 6 and 13: can you see progress, and is the code yours?
Frequently asked questions
A small company or a large one?
Size alone doesn't decide. With a small company, what matters is whether the founding team actually works on the project; with a large one, where your project sits in their priorities. Question 4 answers both.
Is working with a freelancer risky?
Dependence on one person is the biggest risk: illness, workload or departure stops the project. It can suit small-scope work; enterprise, long-lived systems need a team of at least two with a process owner.
A local company or one abroad?
The same time zone, the same language and knowledge of local regulation are measurable advantages in enterprise projects, and contract and dispute management is easier. A company abroad should be chosen only for expertise not available locally.
Conclusion
The right company is the one that isn't bothered by your questions, answers them concretely, and keeps the code, the data and the process in your ownership. Ask these 20 questions in every meeting, write down the answers and score them; the decision usually reveals itself.
You can get our answers to these questions in a discovery call: see our enterprise application development process and our maintenance and support coverage. The discovery call and first estimate are free.