Questions to ask a software development company before you hire, and what good answers sound like

Questions to ask a software development company: the short answer

The questions to ask a software development company are the ones whose answers you can check. Ask how it uses AI and who reviews the output, how it knows the software works, what happens when it breaks, and what you'll get at handover. Then ask to see something behind each answer: a test, a staging site, a weekly update, a handover document.

This guide is for founders and operations leads at UK and EU companies of 10 to 200 people. You're hiring a company to build a web application or an internal tool, and you don't need to read code to use this list. Each group of questions comes with what a good answer sounds like, and what should worry you.

Three questions come before all of these: who owns the code, who you'll talk to, and what's in the written scope. Our guide on how to choose a software development company covers them. This list picks up where that one stops.

If you'd like someone technical on your side while you compare answers, our software consulting gives you an honest read before you commit, in writing.

How to judge an answer when you can't judge the code

You can't read a developer's code in a sales meeting. You can read the shape of an answer, and it tells you more than most buyers expect. A good answer does three things.

1. It names things: people, tools, documents, dates. "Our lead engineer reviews every change before it's merged" says more than "we have strong quality processes".
2. It shows you something you can look at today, such as a test, a staging link, or a handover document from a past project with the client's details removed.
3. It admits a limit: what the company doesn't do, where your project's risk sits, or what it's least sure of.

An answer that does none of the three is a promise, and promises are free to make in a pitch. You don't have to understand the evidence fully. You only have to notice whether there is any.

We think the information gap between buyer and developer is the developer's to close, not to profit from. A company that explains its reasoning leaves you better able to judge the work each month. That's the company you want when month six gets difficult.

Ask how it uses AI, and who checks what it writes

Assume any company you talk to uses AI for some of its code. The questions are which parts of the work AI does, who reviews each change before it reaches you, and what goes into the AI tools.

Press on the review. In a July 2025 study by METR, 16 experienced open-source developers took 19% longer to finish their tasks when they were allowed AI tools. Afterwards, they still believed AI had made them 20% faster.

The authors warn against reading this as true of all developers. It does show that how fast AI feels is poor evidence of what it delivers.

Speed is the smaller worry. Veracode, which sells code security testing, gives AI models set coding tasks and checks the results for security flaws. In its March 2026 update, only 55% of the tasks produced secure code across the models it tested. That's about the same share as in its 2025 report, even though the models now get the syntax right more than 95% of the time.

Code that runs and looks finished is exactly what AI makes cheap. The person checking it is what you're paying for.

A good answer sounds like this: "AI drafts most of the code. Our lead engineer reviews every change before it's merged, and nothing reaches your staging site without that review. Here's a recent change with the review comments on it."

Then ask what goes into the tools. If the company will see your code or your customers' data, ask which AI tools it uses and on which plan. Ask whether the provider may train on what goes in. The answer should come from the provider's terms, not from memory.

Worry when you hear about speed and nothing about review, or when nobody can say which tools the team uses. Our own answer is on our homepage. AI does most of our production and none of the direction. A person makes the architecture, interface and copy decisions, and a person reviews the output before you see it.

Ask how it knows the software works, and ask to see a test fail

Every company says it tests. The useful questions are what it tests, where, and how it knows the tests would catch a problem.

Start with the rules that would cost you money or trust if they broke. Who can see which records? How is an invoice total worked out? What happens when a payment fails?

Ask which of these the company tests automatically on every change. A good answer names them. A worrying one says "we test everything".

Then ask to see a test fail. A passing test proves nothing on its own. It proves something only if it would fail when the code breaks, and some tests would pass either way. A good developer can break one rule on purpose, in front of you, and show the test turning red.

Last, ask where the testing happens, and how close that place is to the live system. TSB's 2018 move to a new banking platform shows why. The bank's independent review by Slaughter and May found that its two new data centres, meant to match, were set up differently in places. Performance tests ran on only one of them, so the difference couldn't show up before go-live.

TSB's own summary says the board had written and oral assurances from its suppliers before it went ahead. Regulators later found that TSB had failed to manage the risks of outsourcing its IT to its critical supplier. Your project is far smaller than a bank's, but the question is the same: is the test setup like the live one?

Finally, try the unhappy paths yourself on the staging site: a wrong password, an empty list, a user without permission, a card that fails. A demo on the happy path shows the easy part. Well-built software also fails quietly, and a page that couldn't load its data can still look complete.

The unhappy paths are where you find out what you're buying. In our web application work, every state is designed, including empty, loading, error and permission denied. Clients click through a shared staging site while the work is under way.

Ask what happens when it breaks after launch

Every system breaks at some point. What matters is who finds out first: the developer, you, or your customer. Ask four things.

• How will you know something is wrong before our customers tell us?
• Who responds, and how quickly, at night and at weekends?
• What do we get in writing after an incident?
• What does support cover, and do we have to buy it?

A good answer lists what's monitored and who gets the alert: errors, slow pages, failed background jobs, certificates about to expire. It puts response times and hours in a written support agreement. After an incident, it gives you a short note: what happened, who was affected, what was fixed and what changes so it doesn't happen again. "Just email us if anything's wrong" is the answer to worry about.

The UK government's voluntary Software Security Code of Practice, published in May 2025, backs these questions. Its 14 principles include telling customers what support and maintenance they get, and telling them about incidents that could seriously affect them. The code says customers may refer to its principles in negotiations and contracts. It's written mainly for companies selling software products, but the questions fit a custom build too.

Our own support is optional and agreed at handover. When a client wants it, we monitor errors, slow queries, failed jobs and expiring certificates, so a problem reaches you from us rather than from a customer. A 24/7 assistant connected to the live system acts on what it can and escalates to a person when it shouldn't be guessing. You own the system either way, so you can take the support elsewhere.

Ask how it stays secure and up to date

Buyers get security questions wrong in two ways: they ask nothing, or they ask for a certificate and stop there.

Ask which security standard the company builds to. A good answer names one, the level, and the parts that apply to your project. "Security is our top priority", with nothing after it, isn't an answer.

One standard to know by name is OWASP's Application Security Verification Standard. It has three levels, and one of its stated purposes is to give a basis for security requirements in contracts.

If the company is in the UK, ask whether it holds Cyber Essentials. The NCSC's Cyber Essentials page links to a search of current certificates, so you can check the answer. Know what it covers. It checks five controls on the company's own systems: firewalls, secure configuration, security updates, user access and malware protection.

That matters, because those laptops and accounts will hold your code and your data. It says nothing about the software the company builds for you.

Then ask what will need updating after launch, and how you'll know. Every system runs on software with an end date. Node.js, which runs the server side of many web applications, typically fixes critical bugs in each long-term support version for 30 months, then stops.

A good answer lists the parts with end dates and says who tracks them. The government code asks software sellers to give at least a year's notice before support ends, which is fair to ask of anyone.

If the company will handle personal data for you, UK GDPR needs a written contract between you. The ICO lists what that contract must include. A company that has done this before will send its draft without being chased.

Ask whether another developer could take over

Every supplier promises you won't be stuck with it. These questions ask it to prove that.

• What happens if our lead developer leaves in the middle of the project?
• What documentation will we get, and can we see an example from a past project?
• Could another developer run the system from your handover, without calling you?

A good answer to the first names a second engineer who already knows the code, and says decisions are written down as they're made. Worry at "that won't happen". People leave, get ill and go on holiday.

For the second, read the example. A useful handover covers how to set the system up from scratch, every account and service it depends on, and the decisions behind it with their reasons.

The most useful part describes how the system connects to things outside itself: payment providers, scheduled jobs, email services. A new developer can read the code in front of them, but can't see what it's wired to.

The third question is the leaving test from our guide to whether you own your website, and its checks work for any software. Our own handovers include documentation written for the next engineer. Your domain, hosting, repository and documentation sit in your own accounts.

Listen to the questions they ask you

The questions a company asks you show as much as its answers. In a first conversation, a good developer wants to know:

• Who will use it all day, and on what devices?
• How does the work run today: which spreadsheets, which inbox, which person?
• What must never go wrong, and what happens now when it does?
• Which systems does it have to connect to?
• Who on your side decides when people disagree?

A company that quotes before asking any of these is pricing a guess. One that asks, then tells you part of your list isn't worth building, is showing you the judgement you're paying for. When we build internal software, we map how the process runs today before anything is built, because the real work often differs from the process document.

All the questions on one page

Send the questions that matter most to every company on your shortlist in one email, so any difference in the answers comes from the companies. Then put the replies side by side.

For ownership, access and scope, the table in our guide to choosing a development partner works the same way.

When you don't need all of these questions

Some projects don't justify the full list, and some buyers need a different step first.

• The job is one small change to a system that already works. Ask the testing and handover questions and skip the rest.
• You're buying a product, not commissioning a build. The questions then go to the product's vendor, where the government code fits even better. Our comparison of custom software and off-the-shelf tools helps you decide which you're doing.
• Your current developer already answers these well. Keep them, because switching carries its own risk.
• You can't tell whether the answers are good. Bring in someone technical you trust, or get an audit and a written recommendation first. That's how we start when we take over a codebase, and sometimes the honest answer is that you don't need to hire anyone yet.

This week, pick the five questions that match what worries you most about the project. Send them in one email to every company on your shortlist, and ask for one thing you can see behind each answer. The replies will sort your shortlist faster than any pitch.

Questions

Should we ask to see code from a past project?

You can ask, but a good company will often say no, because the code belongs to its clients. Ask instead for a handover document or setup guide from a past project, with the client's details removed. If you already have a system, a short paid review of your own code shows you how the company thinks, on something you care about.

Is 'it depends' a bad answer?

Only when nothing follows it. 'It depends on how many kinds of user you have and whether you take payments; for what you've described, I'd expect this' is an honest answer. 'It depends' followed by a change of subject means the company hasn't thought about it, or doesn't want to say.

Do the same questions work for a freelancer?

Most of them do. Press hardest on continuity, because a freelancer's holiday or illness stops the work, and there may be nobody else who knows the code. If the freelancer holds no security certificate, ask how they protect their own laptop and accounts. The testing and handover questions apply unchanged.

How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.