Most due diligence on software development companies happens in the wrong order. A business receives a proposal, gets excited about the price or the portfolio, asks a few friendly questions on a discovery call, and signs the contract. The uncomfortable questions come later — when a deadline is missed, when the code is unmaintainable, or when the company becomes unresponsive after payment is received.
The 15 questions below are designed for the evaluation stage — before any contract is signed. They are weighted toward uncovering hidden risk rather than confirming a decision you have already made emotionally.
Questions about process and delivery
1. What does your project kick-off look like, and what do you need from us before work begins?
A company that has a real process will give you a specific answer: discovery session, technical requirements document, architecture review, signed brief. A company making it up will say "we get started pretty quickly" or "just send us the details and we'll begin."
What you learn: whether they have a repeatable process, or improvise.
2. How do you handle scope changes after the contract is signed?
There are only two honest answers: a change request process with written estimates and approvals, or a time-and-materials model where additional hours are billed. Any other answer ("we're flexible, we'll work it out") suggests the contract terms will become a point of dispute.
What you learn: whether scope changes will surprise you financially.
3. What project management tool will you use, and what level of access will we have?
Any legitimate software company operates in a tool you can see (Linear, Jira, Asana, Trello). If they cannot name a tool or offer you access to it, you will have no visibility into progress.
What you learn: whether you will actually be able to see work happening.
4. How frequently will we receive working software to review?
The answer you want: weekly deployments to a staging environment, or at minimum a fortnightly demo. The answer that should concern you: "we'll deliver at the end of the project" or "we'll share when it's ready."
What you learn: how early you can catch problems.
5. What is your QA process?
Look for: developer testing, a separate QA function, automated tests, a staging environment for final checks before production. If QA is "the developer tests their own work before delivery," that is the minimum acceptable. No mention of QA at all is a flag.
What you learn: whether bugs will be caught before they reach you.
Questions about team and continuity
6. Who specifically will work on our project, and can we meet them before signing?
A company confident in its team will introduce you to the actual developer or lead who will work on your project. A company that says "our team will handle it" without naming names may be using marketplace or subcontracted freelancers — which changes the accountability model significantly.
What you learn: whether you are buying a company relationship or an individual you can be swapped out of.
7. What happens if the developer assigned to us leaves the company or becomes unavailable?
Every company should have a clear answer here. Replacement within a defined period, a documented transition plan, no billing gap during transition. A company that hesitates or says "we'll deal with that if it happens" is not planning for continuity.
What you learn: your risk exposure if the relationship breaks down at the individual level.
8. What is your team's primary location, and what are the working hours I can expect?
Many companies say "we have a team in [country X]" while the actual work is done by subcontractors in different countries with different timezone and communication patterns. Ask directly. A company uncomfortable with this question is telling you something.
What you learn: who is actually doing the work and when they will be available.
Questions about code and handover
9. Who owns the code during and after the engagement?
The only acceptable answer is: you do. Immediately. Any suggestion that code ownership is conditional on final payment, or that IP assignment requires a separate negotiation, is a flag. Ensure the contract states IP assigns to you upon creation, not upon payment.
What you learn: whether you could leave the engagement with your code at any stage.
10. What does the handover documentation look like at the end of the project?
Look for: README, deployment instructions, environment variable documentation, database schema notes, third-party integration credentials list. A company that does not produce handover documentation is producing a black box you will need their help to maintain forever.
What you learn: whether you will own the outcome, or just the relationship.
11. Can I see a sample of code from a previous project, or a public GitHub repository the company maintains?
Portfolio screenshots show UI. Code samples show engineering quality. A company confident in its technical work will have something to show — open-source contributions, a demo repository, a code sample with NDA redactions if necessary.
What you learn: whether the technical quality matches the marketing quality.
Questions about past performance and references
12. Can you share two or three clients I can contact as references? What should I ask them?
Structured staffing companies and software agencies with a real track record will have clients willing to take a reference call. The offer to guide your questions is also telling — a company that says "ask them anything" is more confident than one that says "they're very busy, but maybe email them."
What you actually ask the reference: Was the project delivered on time? Were there any budget overruns? How did they handle problems when they arose? Would you use them again?
What you learn: what the experience is actually like, from someone who has had it.
13. Have you worked with businesses of similar size and in our industry before?
Not a qualifier — an exploration. A company that has never built a SaaS product will face a learning curve on your SaaS product. That is acceptable if the price reflects it. What you are checking is whether they are presenting false experience.
What you learn: how much runway they have for your specific context.
Questions about the commercial structure
14. What is included in the monthly/project price, and what will incur additional billing?
Every proposal should have a clear list of what is in scope. Ask explicitly: Are server costs included? Third-party API fees? Bug fixes after delivery? Design work? Monthly maintenance? Surprises on scope are the primary source of invoice disputes.
What you learn: the real cost of the engagement, not the headline number.
15. What are the exit terms if the engagement is not working?
This question makes many companies uncomfortable, which is itself a signal. A legitimate company has clear notice periods (typically 30 days), a process for transferring code and documentation, and a defined responsibility for ongoing tasks. An opaque answer here suggests the exit will be difficult by design.
What you learn: how trapped you will be if you need to leave.
What to do with the answers
A company that answers all 15 questions clearly, confidently, and with specific examples is demonstrating operational maturity. A company that deflects, hedges, or answers with vague reassurances is showing you what the engagement will feel like.
No company is perfect. But the gap between "here is our specific process for X" and "we'll work it out" is the gap between a company that has done this before and one that is figuring it out with your budget.
The related due diligence guide for choosing a company in Pakistan specifically covers the additional checks relevant to offshore providers — regulatory, communication, and contractual protections that matter when the company is in a different legal jurisdiction.
Codalyst Tech answers all 15 of these questions on any discovery call. We can share references, introduce you to your developer before you sign, and provide a company-level contract with full IP assignment.