Questions to Ask a Software Development Company

Use this list on your next three calls

Ask every shortlisted vendor the same 12 questions in the same order, and score the answers in writing. The questions target hidden subcontracting, key-person risk, locked-in code, open-ended change pricing and vague acceptance.

Most published questions to ask a software development company cover portfolio, communication tools and time zones. Those are easy to answer well in a pitch. The 12 below are different because a vague answer is itself information.

Split them across three calls. Call one covers people and code. Call two covers contracts and money. Call three covers delivery and failure.

How to choose a software development partner with these 12 questions

The table is the whole list on one screen. The sections that follow explain what to listen for.

How should you score the answers?

Score each answer 0, 1 or 2 and total it per vendor. A 2 means a specific, checkable answer. A 1 means a plausible answer with no evidence. A 0 means evasion or a red flag.

Do the scoring on the same day, before the sales follow-up arrives. Memory flatters whoever spoke last.

Who writes the code (and how to verify it)

Ask who physically writes the code, whether they are employees or contractors, and how you can inspect the work. The answer should include named engineers and read access to the repository during the build, not only demos.

Question 1: Who writes the code?

Many agencies sell with senior people and staff with juniors or subcontractors. Subcontracting is not automatically bad, but it must be disclosed. Ask for the names, seniority and employment status of the engineers who will be on your project, and whether any work leaves the vendor's own team.

Ask this too: who reviews the code before it merges? If the answer is "the same person who wrote it", there is no review.

Question 2: How can I verify the work as it happens?

A demo shows that something runs. It does not show whether it is maintainable. Ask for read access to the repository, the pull request history and the CI results from week two onward.

GitHub's documentation on protected branches describes required reviews and status checks. Ask whether the vendor enforces those settings. You do not need to read every line. You need to see that review happens, tests run and commits are small.

NIST's Secure Software Development Framework (SP 800-218) is a useful yardstick for the security practices to ask about.

What happens when the lead leaves

Ask who your technical lead is, who their named deputy is, and what happens if the lead resigns mid-project. A mature vendor can describe a handover process and show that at least two engineers understand your codebase.

Question 3: What if the project lead leaves?

Key-person dependence is the most common hidden risk in outsourced builds. People change jobs, and a vendor that says it will not happen has not thought about it.

Listen for specifics: a documented architecture decision log, a deputy who joins standups, a defined overlap period for any replacement, and who pays for the ramp-up time. If the replacement cost lands on you, that belongs in the contract.

Question 4: Who else understands my codebase?

Ask how many engineers have committed to the repository in the last month on a comparable project. One name in the commit history is a single point of failure, however good that person is.

This is where company age matters less than structure. Viithiisys has shipped since 2007, which is 19 years and 500+ projects, but the useful follow-up for any vendor is the same: how is knowledge spread across people rather than held by one of them? If you are short on senior technical judgement yourself, a fractional CTO can sit on these calls and interrogate the answers for you.

Who owns the IP, and what are the repo access and escrow terms?

Ask who owns the IP, where the repository lives and how you leave. The right answers are that you own the work as it is created, the repo sits in your organisation from day one, and exit comes with a defined handover.

Question 5: Who owns the IP, and when?

Some contracts transfer ownership only on final payment. That gives the vendor use in any dispute. Ask for assignment on creation, with the vendor's pre-existing tools and libraries licensed to you in perpetuity.

Under US law the position is not what many buyers assume. The US Copyright Office's guidance on works made for hire explains that commissioned software by an independent contractor generally needs a written agreement to transfer rights. Have counsel check it.

Question 6: Where does the repository live?

The repo should sit in a GitHub, GitLab or Bitbucket organisation you own, with the vendor invited as collaborators. Then access cannot be withdrawn as a negotiating tactic, and you can revoke it yourself.

If the vendor insists on hosting the code in their account "for convenience", ask for a mirror to your account that updates on every push. Also ask who holds the cloud credentials, the domain registrar login and the app store accounts.

Question 7: What is the exit path, and is escrow worth it?

Ask what a termination looks like: notice period, handover package and any fees. Then ask about source code escrow, where a neutral third party holds the code for release on defined triggers such as vendor insolvency.

Escrow matters mostly when the vendor hosts the code or runs the production system. If you own the repo and the cloud accounts, escrow adds little. Do not pay for protection you already have.

How are change requests priced?

Ask how a change request is raised, estimated and approved, and what counts as a change versus a defect. The answer should be a written process, not a rate card recited from memory.

Question 8: What counts as a change, and who decides?

Most scope disputes come from one unanswered question: is this a defect in the agreed scope or a new requirement? Ask for the definition in the contract, plus a worked example from a past project.

Then ask who can approve a change on your side. If any stakeholder can add scope by email, the budget will drift.

Which engagement model absorbs change best?

Fixed-scope work protects your budget but makes changes explicit and negotiated. Time-and-materials absorbs change easily but moves the cost risk to you. Neither is better in general.

Viithiisys's Moonship MVP is the fixed end of that spectrum: a working MVP in 30 days against a fixed scope, where anything outside the scope is a separately agreed change. For open-ended product work, ask the vendor to explain how they would cap spend per sprint. Pricing for either model is scoped per project after a discovery call.

What was their last failed project?

Ask for a specific project that failed or nearly failed, the root cause, and what the vendor changed afterwards. How they answer matters more than what they say.

Question 9: Tell me about a project that went wrong

Good answers are specific and unflattering: a misjudged integration, an estimate built on an unvalidated assumption, a client sponsor who left. They end with a changed practice, such as an earlier spike on risky integrations.

Bad answers blame the client, or reframe a success as a "challenge overcome". Ask for the reference on that project too, not the happiest one.

Which references should you ask for?

Ask for three: a recent client, a client from a project over two years old, and one where the scope changed heavily. Older projects show whether the code survived. Heavy-change projects show how the vendor behaves under pressure.

Cross-check against public evidence. The vendor's case studies should name real clients and outcomes. Viithiisys, for example, lists work for clients including Paytm, Snapdeal, IKEA, Nestle, Shiprocket and Vikram Solar. Ask any vendor whether you can speak to the people behind comparable ones.

What does onboarding look like in week one?

Ask for the first-week plan in detail. By day five you should have repository access, working environments, a deployed skeleton and a written list of open risks, not a kickoff deck.

Question 10: What have I got by Friday of week one?

Onboarding is where process becomes visible. Ask what you will see on day five: the repository created, CI running, a staging environment deployed with a hello-world build, and an agreed backlog for sprint one.

A vendor that spends week one on discovery workshops and slideware can still be good, but ask what is produced and who signs it off.

What should you prepare on your side?

Delays in week one are often yours. Have ready your decision-maker, access to existing systems and APIs, brand assets, and any data you expect the system to use.

If you are replacing an ageing system, see how the vendor approaches system modernisation, because migration constraints surface in the first week, not the fifth. Ask for a named person on your side too, with authority to say yes.

What is their definition of done?

Ask how the vendor decides a feature is finished. A usable answer lists testable acceptance criteria, automated test coverage expectations, a QA step and a deployment to staging, agreed before development starts.

Question 11: How do you define done?

"Done when the client is happy" is not a definition. It makes acceptance subjective and gives either side an excuse in a dispute.

Ask for a written checklist per story: acceptance criteria met, code reviewed, tests passing, no known critical defects, documentation updated, deployed to staging. Also ask who owns QA and testing, and whether testers are independent of the developers who wrote the code.

Question 12: What do I receive at the end?

Done should include a handover. Ask for the full list: source code, infrastructure-as-code, test suites, runbooks, architecture notes and all credentials transferred to your accounts.

CISA's Secure by Design material is a reasonable reference for what security documentation a buyer can expect from a vendor. Ask for a handover rehearsal: a new engineer should be able to build and deploy the system from the repo and runbook alone.

Answers that should end the call

Stop the process when you hear any of these: no named engineers, repo held back until final payment, no documented change process, no past failure, or acceptance defined as client satisfaction. Each one is a structural risk, not a style choice.

Which red flags are fatal?

These five are rarely fixable by negotiation, because they reflect how the vendor works:

• Refusal of repository access during the build.
• IP that transfers only after the final invoice.
• A single named engineer for the whole project, with no deputy.
• Claims of zero failed projects.
• Pressure to sign before you have seen a draft contract.

What if the answers are mixed?

Mixed scores are normal. Weight questions 5, 6 and 11 highest, because ownership and acceptance are hardest to fix after signing.

Ask us these same 12 questions. We would rather answer them on a call than have you discover the gaps after signing. If you want to check how a broken process is costing you before you shop for a vendor, the broken workflow assessment is the place to start, and you can book 30 minutes with a founder to put the list to us directly. Our teams serve clients in the US, UK and Canada from Mohali and Markham, Ontario.