How to Choose a Software Development Company: 12 Questions to Ask
Twelve questions to ask a software company before you sign, what a good answer sounds like, the red flags to watch for, and how to compare quotes fairly.
Ask every company the same twelve questions and compare the answers side by side. A good studio answers with specifics, shows you working software early, and puts price, scope and ownership in writing. A weak one gets vague, changes the subject or sends another slide deck.
How to use these questions
Before you hire anyone, make sure you need custom software at all. Our post on custom software or off the shelf helps with that. If you do, send the questions by email first. Written answers are easy to compare and hard to change later. Then talk through what you read.
Listen for specific answers: names, dates, examples. "We follow best practices" is not an answer. Where it helps, we add how we answer. We only state what is true for us, and we leave out the rest.
The team and the plan
- Who exactly will work on this? A good answer gives names, roles and years of experience of the people who will write your code, and says whether they are employees or subcontractors. Red flag: a senior person pitches, then a different and more junior team builds. Our engineers are senior, with 8 or more years of experience.
- Can I see something working in the first weeks? A good answer is a dated plan with an early demo. Red flag: "you will see it at the end". We build a working prototype in week one. Our post on what 4 weeks of MVP development buys shows what a focused first version can hold.
- Is it fixed price or hourly, and what happens when scope changes? A good answer explains both and says how a change is written down, priced and approved before work starts. Red flag: a fixed price with no scope document, or hourly work with no cap and no report. We work on fixed price projects.
- How often will I see progress? A good answer is a regular demo of working software, not only status reports. The Agile Manifesto puts it plainly: working software over comprehensive documentation. We give weekly demos.
Ownership and paperwork
- Who owns the code and the IP? (IP means intellectual property.) A good answer is: you do, and it is in the contract. Red flag: they keep the code and license it to you, or tie you to their hosting. Do not assume. In the United States, for example, commissioned work counts as "work made for hire" only for certain kinds of work and only with a signed written agreement (17 U.S.C. § 101). Other countries have other rules, and this is not legal advice, so ask a lawyer. With us, the client owns the code and the IP.
- How do you handle NDAs? A good answer is that they sign yours or offer theirs before you share details. Red flag: they refuse, or want everything from you first. We sign an NDA on request.
- What if we part ways? A good answer is a written handover: you get the repository, the notes, the accounts and the credentials, and the contract says how notice works. Red flag: nothing is written down, or the code lives only on their machines.
Quality and safety
- How do you test? A good answer says what is tested, by whom and before which release, and that key flows have automated tests. Joel Spolsky's well known 12 question test for software teams asks things like whether they use source control, can build in one step and have testers. Red flag: "we test at the end".
- How is security handled? A good answer names practices: access control, secrets kept out of the code, updated dependencies and a review before launch. It may point to a standard such as the OWASP Application Security Verification Standard or the NIST Secure Software Development Framework. Red flag: "we take security very seriously" and nothing behind it.
After the launch and the long term
- What happens after launch? A good answer lists fixes, hosting, monitoring and small changes, what each costs and who to call. Red flag: the project ends on launch day and nobody has thought about the day after. Our process includes an Operate phase, which is ongoing.
- Can I talk to past clients? A good answer is two or three references on similar projects, offered quickly. Ask them whether the work was on time, what went wrong and how it was handled, and whether they would hire the company again. You can also look at the company's own work. Red flag: only anonymous testimonials.
- What do you need from me? A good answer is a short list: a decision maker who replies, access to your tools and data, and feedback after each demo. Red flag: "nothing, we will handle it". Every project needs your decisions.
How to compare quotes
Two quotes can describe two different projects. Put them in one table and fill in every row:
| Compare | Why it matters |
|---|---|
| What is in scope, and what is left out | A low total often hides a smaller scope. |
| Who does the work and their experience | Price follows seniority. |
| Timeline with demo dates | A plan you can check week by week. |
| Price type and the change process | You learn the cost of change before you need one. |
| Ownership and handover | Look for it in writing. |
| What happens after launch | Hosting and support are often priced separately. |
| Payment schedule | Tie payments to work that you have seen running. |
Ask the lowest bidder what is not included. Ask the highest what you get for the difference. A clear scope with a stated timeline makes this easier, which is why our packages show both.
Questions and answers
How many companies should I talk to?
Two or three. With fewer you have nothing to compare, and with more you lose weeks on calls. Give each one the same short brief so the quotes match.
Is fixed price always better than hourly?
No. Fixed price fits a clear scope, because you know the cost up front. Hourly work fits a scope that is not clear yet. Either way, ask for a written scope, a regular budget report and a rule for how changes are approved.
Does the company have to be in my country or time zone?
No, but you need enough shared hours to talk without long delays. 1 o Solutions has offices in Munich and Karachi and works with clients in eight countries, so we are used to working across time zones. Ask about reply times, a fixed demo day and one person you can call.
I am not technical. How can I judge the answers?
Ask for a demo of something running, not slides. Ask them to explain one technical choice in plain words. If they cannot, that tells you something. You can also ask a technical friend to read the proposal. An hour of their time is small next to a failed project.
Is a small studio riskier than a big agency?
The risks differ. A small studio has fewer people, so ask what happens if your lead engineer is ill or leaves. A big agency has more people, so ask who exactly will work on your project. In both cases, the contract and the demos protect you more than the size does.
What should I prepare before the first call?
A short brief: the problem, who will use it, the tools you use today, any deadline and a budget range. You do not need a full specification. A good company helps with the rest.
References and further reading
- The Joel Test: 12 Steps to Better Code joelonsoftware.com Joel Spolsky's quick yes or no test for judging a software team.
- Manifesto for Agile Software Development agilemanifesto.org The short statement that values working software and customer collaboration.
- 17 U.S.C. § 101, Definitions law.cornell.edu The US copyright law text that defines "work made for hire" and the signed agreement it needs.
- OWASP Application Security Verification Standard owasp.org A list of security requirements for designing, building and testing web applications.
- NIST Secure Software Development Framework csrc.nist.gov NIST recommendations for lowering the risk of software vulnerabilities.
If you would like to hear how we answer all twelve, book a free 30 minute call and ask us. We reply within one business day.
