40 Questions to Ask a Software Development Company Before Hiring

Before hiring a software development company, ask about relevant experience, who exactly will do the work, how they plan and report, how they test, how they protect your data, who owns the code, how the price was built and what happens after launch. The 40 questions below are grouped into eight areas, each with a note on what a good answer sounds like. You will not need every question for every project: pick the ones that matter most, send them before the meeting, and ask every shortlisted company the same set so you can compare answers fairly.

Use the questions in two rounds. Send the first three groups in writing with your brief, then use the rest in a call with the people who would work on your project, not only the sales lead.

Experience and fit

• Q1. Which projects have you delivered that are most similar to ours? Good answer: two or three specific examples with the problem, their role and the outcome, not a list of logos.
• Q2. Can we see the product or a demo? Good answer: a live product, a recorded demo or screenshots with an explanation of what they built.
• Q3. What do you think is the hardest part of our project? Good answer: a specific risk, such as an integration, data migration or performance requirement, and how they would reduce it.
• Q4. What kinds of projects do you turn down? Good answer: a clear sense of where they are not strong. Companies that say yes to everything are harder to trust.
• Q5. What would you need from us to succeed? Good answer: a named product owner, timely decisions, access to systems and users, and feedback on demos.

Team and people

• Q6. Who will work on our project, and in which roles? Good answer: names or at least roles and seniority, in writing, with time allocation.
• Q7. Are they your employees or subcontractors? Good answer: a direct answer. Subcontracting is not wrong, but you should know.
• Q8. Can we meet the project manager and lead developer before signing? Good answer: yes.
• Q9. How do you handle staff changes during the project? Good answer: notice to you, overlap and handover at their cost, and your right to object to replacements.
• Q10. What time zone and working hours will the team keep, and how much overlap will we have? Good answer: a defined overlap window and named contacts for urgent issues.

Process and communication

• Q11. How do you start a project? Good answer: a discovery or planning phase that produces scope, priorities, architecture notes and a plan.
• Q12. How do you plan and track work? Good answer: a shared task board you can see, with sprints or milestones and a clear definition of done.
• Q13. How often will we see working software? Good answer: regular demos, typically every one or two weeks, on a staging environment you can access.
• Q14. How do you handle changes to scope? Good answer: a written change process that shows the impact on time and cost before anything is approved.
• Q15. What will you report each week, and to whom? Good answer: progress against plan, risks, decisions needed and budget used.

Technical approach and quality

• Q16. Which technologies do you recommend for us, and why? Good answer: reasons tied to your needs, team, budget and long-term support, not just their favourite stack.
• Q17. How do you test? Good answer: a mix of automated tests, code review and manual QA, with test environments and who is responsible for each.
• Q18. How do you review code? Good answer: every change reviewed by another developer before merging, with agreed standards.
• Q19. How do you deploy? Good answer: automated build and deployment pipelines, separate staging and production, and a rollback plan.
• Q20. How do you use AI coding tools, and how do you check their output? Good answer: an honest description of which tools they use, with the same review, testing and licensing checks as human-written code.

Security and data protection

• Q21. What security standards or certifications do you hold? Good answer: specifics you can check, such as ISO/IEC 27001 (a standard for information security management systems) or a SOC 2 report covering controls relevant to security, availability, processing integrity, confidentiality or privacy, as described by the AICPA. If they hold none, ask what policies they follow instead.
• Q22. How do you build secure applications? Good answer: reference to a recognised baseline such as the OWASP Application Security Verification Standard, plus dependency scanning and security testing.
• Q23. Who will have access to our systems and data, and how is access removed? Good answer: named people, least-privilege access, and removal at the end of the project or when someone leaves.
• Q24. Where will our data be stored and processed? Good answer: specific locations and whether real customer data is ever used in development or testing.
• Q25. What happens if you have a security incident? Good answer: a defined process with a notification time frame you can put in the contract.

Ownership, IP and contracts

• Q26. Who owns the code, designs and documentation? Good answer: you do, with IP assigned on payment, and the contract says so.
• Q27. Will the code be in our repository from day one? Good answer: yes, or at least continuous access to theirs, not delivery at the end.
• Q28. Do you use any of your own frameworks or components we would not own? Good answer: a clear list, with the licence terms under which you can use and modify them.
• Q29. Which open source licences are in the codebase? Good answer: a list, and a policy for avoiding licences that conflict with your plans.
• Q30. What are the termination and handover terms? Good answer: a reasonable notice period and a handover of code, credentials and documentation. Our software development contract checklist covers the clauses to look for.

Pricing and budget

• Q31. How did you build this estimate? Good answer: a breakdown by feature or phase, with hours or effort and the assumptions behind them.
• Q32. Is this fixed price or time and materials, and why? Good answer: a model matched to how certain the scope is. See our guide to fixed price vs time and materials contracts.
• Q33. What is not included? Good answer: an explicit list, such as hosting, third-party licences, content, app store fees or post-launch support.
• Q34. What are the payment milestones? Good answer: payments tied to delivered, accepted work rather than calendar dates alone.
• Q35. How do you handle estimates that turn out to be wrong? Good answer: early warning, options to reduce scope or adjust, and no surprise invoices.

Support, handover and references

• Q36. Is there a warranty period for defects after launch? Good answer: a defined period during which they fix their own bugs at no extra cost.
• Q37. What does ongoing support cost and cover? Good answer: a support plan with response times, hours included and what counts as new work.
• Q38. What documentation will we receive? Good answer: setup instructions, architecture notes, API documentation and deployment steps.
• Q39. Could another team take over the code easily? Good answer: yes, with reasons: standard frameworks, tests, documentation and clean repositories.
• Q40. Can we speak to two clients with similar projects? Good answer: yes, with contact details, ideally including one long-term client.

How to score answers and spot red flags

Score each company from 1 to 5 on each group, weighting the groups that matter most for your project. Security and ownership might carry double weight for a system handling personal data, while process and communication might matter most for a first-time buyer.

Watch for these red flags in the answers:

• Vague answers about who will work on the project.
• A price given before any questions about your users, data or integrations.
• Reluctance to put code in your repository or assign IP.
• No testing approach beyond "we test everything".
• No references, or only references from years ago.
• Pressure to sign quickly with a discount that expires.

Once you have proposals in hand, our guide on how to compare software development quotes explains how to line them up, and the broader guide on how to choose a custom software development company covers the full selection process.

Conclusion

Good questions reveal how a company works, not just what it says in a pitch. Ask every shortlisted company the same questions, insist on specific answers in writing, score them consistently and call references before you sign. To build your shortlist, browse software development companies or search the Trusted IT Firms directory by service, location, team size and hourly rate.

Frequently asked questions

What is the most important question to ask a software development company?

Ask who exactly will work on your project and whether you can meet them. The team you get matters more than the company's portfolio, and vague answers here are a warning sign.

Should I send questions before the first meeting?

Yes. Send the questions on experience, team and process with your brief, so the meeting can focus on details, technical approach and the people involved.

How do I know if a company's security claims are real?

Ask for evidence you can check, such as an ISO/IEC 27001 certificate with its scope, a SOC 2 report under NDA, or written security policies, and confirm what part of the company they cover.

Who should own the code a development company writes for me?

You should, with IP assigned to you on payment and the code kept in your repository throughout the project. Confirm this in the contract, along with any reusable components the company keeps.

Sources

• ISO/IEC 27001 Information security management systems (ISO)
• SOC 2 (AICPA & CIMA)
• OWASP Application Security Verification Standard