SoftwareCrafting Logo

Buyer Checklist

Questions to Ask a Software Development Company

Five questions do most of the work. Here they are, with the answers to listen for.

A good answer is specific and occasionally unflattering. A bad answer is smooth, general, and agrees with everything you said.

5 areas
People, process, code, commercials, exit
Specific
What a good answer sounds like
Ask us
We answer all of these on a first call

Quick Answer

Updated August 22, 2026

What questions should I ask a software development company?

Five questions do most of the filtering: who specifically will write the code and can I speak to them, who reviews their work, what happens when they are unavailable, is the repository under my organisation from day one, and what went wrong on a recent project. Good answers are specific and sometimes unflattering — a named engineer with a background, a described review process, a real story about a failure and what changed after it. Bad answers are smooth and general: "our team", "we have a process", "nothing really comes to mind".

Core questions

5

Full checklist

25 across 5 areas

Best single question

"What went wrong recently?"

Best for

  • Buyers preparing for vendor calls
  • Non-technical founders who need a script
  • Teams that want to compare vendors on the same questions

Not best for

  • Engagements too small to justify a call at all
  • Renewals with a supplier you already know well
  • Formal RFP processes with a mandated question set
Talk to a senior engineer

Side By Side

The questions, and what the answers tell you

Questions to Ask a Software Development Company — side-by-side comparison
QuestionA good answer sounds likeA weak answer sounds like
Who will write the code?A named person, their background, and an offer to put them on a call"Our team of experienced developers"
Who reviews their work?A described review process with a second named engineer"We have senior oversight"
What happens if they are unavailable?A specific cover arrangement, included in the rate"That does not usually happen"
Who owns the repository?Yours, under your organisation, from the first commit"We hand everything over at the end"
What went wrong on a recent project?A concrete story and what they changed afterwards"Nothing really comes to mind"
How did you arrive at this estimate?A range with the assumptions named next to itA single confident number with no working
What is excluded from this quote?A clear list — hosting, third-party fees, maintenance"Everything you need is included"
What would make you turn this project down?A real answer about fit and capacity"We can build anything"

Each Option In Detail

What each one is actually good and bad at

People and accountability

Who does the work, who checks it, and who is responsible when it slips.

Five minutes of a first call

Strengths

  • Who exactly will write the code, and can I speak to them before signing?
  • How many years have they worked at this seniority, and on what?
  • Who reviews their code, and how does that review actually happen?
  • Who do I contact when a sprint slips, and what will they be able to change?
  • What happens if that person leaves your company mid-engagement?

Limits

  • Some agencies genuinely cannot answer until a project is assigned
  • Named engineers can still change for legitimate reasons

Best for: Establishing whether the people selling are connected to the people building

Process and quality

How work moves from a brief to something running in production.

Ten minutes, and worth every one

Strengths

  • What does your testing look like, and is it included in the rate?
  • How do you handle a requirement that turns out to be wrong mid-sprint?
  • What documentation will exist at the end, and who writes it?
  • How often will I see working software rather than a status update?
  • What is your deployment process, and can I see a pipeline you built?

Limits

  • Process descriptions are easy to rehearse
  • Cross-check the answers against the trial rather than trusting them

Best for: Predicting what the engagement will feel like week to week

Code and ownership

Whether what you are buying will still be usable by someone else later.

Five minutes, and it prevents the worst outcomes

Strengths

  • Is the repository under my organisation from the first commit?
  • When is IP assignment signed, and can I see the clause?
  • Can you show me a codebase you built that another team took over successfully?
  • What is your policy on third-party dependencies and licences?
  • Who holds the production credentials and the store signing keys?

Limits

  • Some agencies reasonably keep internal tooling proprietary
  • A perfect answer here does not guarantee good code

Best for: Making sure you own what you paid for, in practice and not only on paper

Commercials and exit

What it costs, what it excludes, and what leaving looks like.

Ten minutes, before you sign anything

Strengths

  • What is explicitly excluded from this quote?
  • How do you handle scope changes, and what does that cost?
  • What is the notice period, and are there penalties for ending early?
  • What exactly happens at handover, and is it billable?
  • What are your maintenance terms after launch, in writing?

Limits

  • Small vendors may not have formal answers to all of these
  • A vendor unwilling to discuss exit terms is telling you something

Best for: Understanding the downside before you are committed to it

Decision Guide

If this is true, choose this

Decision rules for questions for a software development company
IfChooseWhy
They will not name the engineerTreat it as a serious warningIt usually means assignment happens after signing, from whoever is free.
They cannot describe a recent failurePush once, then discount themEveryone who ships has failures. Being unable to name one is a candour problem.
The estimate has no assumptions attachedAsk for them in writingAssumptions are where every later disagreement is going to come from.
They agree with everything you proposeBe cautiousA supplier who never disagrees during sales will not warn you during delivery either.
They tell you the project is not a fit for themTake them seriously and stay in touchTurning down revenue is the most reliable honesty signal in this industry.

The Honest Take

Ask us all twenty-five

We answer every one of these on a first call, including the uncomfortable ones. Our engineers join sales calls, the repository is under your organisation from the first commit, the contract is monthly rolling with two weeks notice, and when you ask what went wrong recently you will get a specific story rather than a deflection. If a question on this list makes any vendor — us included — visibly uncomfortable, that discomfort is the most useful piece of information you will get in the whole process.

Do not hire us if any of these is true

  • You need scale or certifications a small senior team cannot provide
  • You would prefer a supplier who does not challenge the brief
  • Price is the only criterion and you accept the variance that comes with it
  • The technology is outside what we work in — we will say so on the first call

Still Deciding?

Send the brief and we will tell you which option fits

Including when that option is not us. A senior engineer reads every brief and replies with the lightest sensible next step rather than the largest one.

Quick Brief

Start the conversation here

Tell us what you are weighing up. We will say which option fits and why, even when it is not us.

Your Name

Work Email

What do you need help with?

Get an honest recommendation

FAQ

Questions people ask about questions for a software development company

What are the most important questions to ask a development company?

Who specifically will write the code and can I speak to them, who reviews their work, what happens when they are unavailable, is the repository mine from day one, and what went wrong on a recent project. Those five reveal most of what matters.

What is a red flag in a vendor answer?

Generality where specificity was possible. "Our team" instead of a name, "we have a process" instead of a description, "nothing comes to mind" instead of a failure story. Also agreeing with everything — a vendor who never pushes back during sales will not push back later.

Should I ask about failed projects?

Yes, and it is the single most revealing question on the list. Everyone who ships regularly has had something go wrong. A vendor who can describe one specifically, and what they changed afterwards, is telling you they learn and that they will be straight with you.

What should I ask about pricing?

What is excluded, how scope changes are handled and priced, what the notice period is, whether handover is billable, and what maintenance costs after launch. Exclusions are where most quote gaps hide.

How many vendors should I ask these questions?

All three on your shortlist, using the same questions, ideally in the same week. Comparing the answers side by side is far more informative than comparing proposals, because proposals are written and answers are not.

Ready when you are

Not sure
where to start?

Tell us your goal and we'll suggest the smallest, fastest way to get there. We reply in under 4 working hours.