How to choose a software development company: 12 questions to ask before you sign

Why the questions matter more than the proposal

If you are working out how to choose a software development company, the proposal is the least reliable thing you will see. Every shortlist looks capable on paper. What separates them is how they behave once requirements change, a deadline slips or a bug reaches production, and you only find that out months in, after the budget is committed.

The way to find out sooner is to ask pointed questions before you sign and to listen for specific answers. Below are the 12 questions we would want answered if we were hiring a software development partner ourselves. They are grouped by what they test: experience and team; cost, process and ownership; security, quality and support; and how the relationship works.

For each question you will find what a good answer sounds like and what should make you pause. They apply whether you are commissioning bespoke software, a customer portal, an ERP or a SaaS product, and whether the team sits in the UK or works remotely.

Experience and team

1. Have you built something like this before, and can I speak to that client?

You are not looking for an identical project. You are looking for one with the same hard parts: the same kind of integrations, data volumes, users or regulation. A team that has built a multi-tenant SaaS platform will already know the traps in yours; a team that has only built brochure websites will learn them on your budget.

Ask for a case study with named outcomes, then ask to speak to the client. A reference call is the single best test you have, because a past client will tell you how the team handled the moments that went wrong.

• Good sign: a relevant example, a stack they can explain, and a client who will take your call.
• Pause if: every example is under NDA, the portfolio is all visuals and no outcomes, or reviews exist only on their own website.

2. Who exactly will work on my project?

Many software development agencies win work with senior people and deliver it with whoever is free. Ask for the names and roles of the people who will write your code, who leads the project day to day, and how much of their time is yours.

Also ask what happens if one of them leaves mid-project. A good answer covers handover notes, shared code ownership within the team and a notice period, not just "we have a big bench".

• Good sign: named people, a technical lead you have met, and an honest view of how many projects each person carries.
• Pause if: the people on the sales call will not be on the project, or the team is described only as "resources".

3. How will you work out what we actually need?

The most expensive mistakes in software are made before any code is written: a missed requirement, a wrong assumption about users, an integration nobody priced. A strong partner proposes a discovery or scoping phase before committing to a full build, and can show you what it produces, such as user journeys, a prioritised feature list, wireframes and a technical approach.

• Good sign: they question your brief, suggest cutting or delaying features, and tie the estimate to what discovery finds.
• Pause if: they quote a fixed price for a full build after a single call, with no questions about your users or existing systems.

Cost, process and ownership

4. How do you price, and what happens when the scope changes?

Scope always changes. The question is who pays for it and how the decision is made. Most software development companies offer one of two models. A fixed price suits a small, well-defined piece of work. Time and materials suits anything where you expect to learn as you go, which is most products.

Neither is wrong. What matters is that the change process is written down: how a change is requested, estimated, approved and billed. Ask to see their change request template and a sample invoice.

• Good sign: they explain which model fits your project and why, and quote a range with the assumptions listed.
• Pause if: the quote is far below the others with no explanation, or a fixed price comes with a vague specification. The gap usually returns later as change requests.

5. What will I see each week?

You should never have to ask whether the project is on track. Ask what you will receive and how often: a working demo, access to a test environment, a visible task board, a short written update on progress, risks and decisions needed from you.

• Good sign: regular demos of working software, not slide decks, and a named person who reports progress honestly, including bad news.
• Pause if: progress is reported as a percentage complete, or you will not see working software until the end.

6. Who owns the code, and when?

This is the question buyers most often forget. Under UK copyright law, code written by an outside company generally belongs to that company unless the contract assigns it to you in writing. Paying the invoice does not, on its own, make you the owner.

Ask for three things: a written assignment of intellectual property to you, the code kept in a repository you own or can access from the start, and a list of any third-party or open-source components with their licences. If the company reuses its own internal libraries, agree a licence that lets you keep using them if you part ways.

• Good sign: IP assigns to you on payment, and the repository sits in your account or is shared with you from week one.
• Pause if: they keep the code until the final payment and give you no access before then, or the contract is silent on ownership.

Security, quality and support

7. How will you handle our data and keep the system secure?

If the software touches personal data, the company building it is usually acting as a data processor for you under UK GDPR, and you need a written data processing agreement with them. Ask whether they have one ready, where your data and test data will be hosted, and who on their team can access production systems.

Then ask how security is built into the work itself: code review, dependency scanning, secrets kept out of the codebase, and access removed when someone leaves the project. If your clients will ask you for certifications such as Cyber Essentials or ISO 27001, ask whether the supplier holds them and request the certificate rather than a logo.

• Good sign: a data processing agreement on the table without prompting, and specific answers about access and hosting.
• Pause if: real customer data is copied onto developers' laptops for testing, or security is described only as "we use secure servers".

8. How do you test, and how do we sign off?

Ask what is tested automatically, who tests manually, and what happens to a bug found after you have accepted a release. Then agree how acceptance works: what you will test, how long you have, and what counts as a defect rather than a new request.

• Good sign: automated tests run on every change, a separate test environment, and acceptance criteria written per feature.
• Pause if: testing means "the developer checks it", or acceptance is assumed once a release goes live.

9. What does support look like after launch?

Launch is the start of the software's life, not the end of the project. Security updates, hosting, bug fixes and small improvements all carry ongoing cost, and you need to know it before you commit.

Ask what a support agreement includes, the response times for urgent and routine issues, and what a typical monthly cost looks like for a system of your size. Response times should be written into the agreement, not promised on a call.

• Good sign: a clear support offer with defined response times, and honesty about what maintenance will cost each year.
• Pause if: support is "we'll sort something out", or the only option is to call them and see who is free.

How the relationship works

10. What happens if we decide to part ways?

Nobody wants to plan the end of a relationship at the start, but this is the question that protects you most. If the partnership stops working, you need to be able to hand the system to another team or bring it in-house without starting again.

Ask what a handover includes: source code, documentation, infrastructure access, deployment instructions and a set number of hours to brief the next team. Check that hosting, domains and third-party accounts are registered to your business, not theirs.

• Good sign: a handover clause in the contract, and infrastructure set up in your own cloud or hosting account.
• Pause if: everything runs on their servers under their accounts, or the answer to "could another team pick this up?" is a laugh.

11. How will we communicate, and who is our point of contact?

Most project problems are communication problems. Ask who your single point of contact is, which tools you will use, how quickly messages are answered, and when you can reach the team live.

If you are outsourcing software development to a team in another time zone, ask how many working hours overlap with yours and which meetings fall inside them. A few hours of overlap each day is usually enough when the process is good; none at all puts a day's delay on every question.

• Good sign: a named contact, a regular meeting rhythm, and a clear answer on overlap hours.
• Pause if: you will be talking to a different account manager each month, or developers are not allowed to speak to you directly.

12. What would you advise us not to build?

This is the honesty test. A partner with your interests at heart will tell you which features to cut, which to postpone, and where an off-the-shelf tool would serve you better than bespoke software. A company that agrees with every idea in your brief is optimising for the size of the invoice.

• Good sign: they push back on part of your brief, with a reason, and suggest a smaller first release.
• Pause if: everything is possible, nothing is a risk, and the estimate grows with every idea you mention.

Red flags when choosing a software development partner

Some warning signs show up before you ask a single question. Any one of these is worth a direct conversation; two or more is usually a reason to walk away.

• A quote far below everyone else's, with no explanation of what has been left out.
• Pressure to sign quickly, such as a discount that expires this week or a team that is "only free now".
• No reference clients, or reviews that appear only on the company's own website and not on independent platforms such as Clutch or GoodFirms.
• A senior sales team you never see again once the contract is signed.
• Ownership terms that favour the supplier, such as code held back until final payment or hosting in their name.
• No questions about your business. A team that does not ask about your users, processes and existing systems is quoting for a product it has imagined, not the one you need.

How to use these questions on your shortlist

Ask the same questions of every company, in the same order, and score the answers straight after each call. Comparing notes from memory a week later favours whoever was most charming, not whoever answered best.

1. Shortlist three or four companies. More than that and the comparison gets shallow.
2. Send your brief and these questions before the first call, so each company can prepare specific answers.
3. Score each area from 1 to 5 using the scorecard below, and write one line on why.
4. Take up references for your top two before you ask for a final proposal.
5. Have a solicitor review the contract, with particular attention to IP, data protection, liability and termination.

Frequently asked questions

How many software development companies should I speak to?

Three or four is usually right. Fewer gives you no real comparison; more makes it hard to compare answers in depth, and good companies will put less effort into a pitch they see as a long shot.

Should I choose a UK software development company or an offshore team?

Location matters less than process, ownership terms and communication. A UK company is easier to meet in person and works your hours. A remote or offshore team can cost less and still work well if working hours overlap and the questions above have strong answers. Judge each company on those answers, not on its postcode.

Is the cheapest quote ever the right choice?

Sometimes, for small and tightly defined work. For anything larger, a quote well below the others usually means something has been left out, a less experienced team, or costs that return as change requests. Ask each company to list its assumptions so you can compare like with like.

Do I need a technical person on my side to choose well?

It helps but is not essential. These questions are written so a non-technical buyer can judge the answers. If the project is large or business-critical, an independent technical adviser for a few days of review is usually money well spent.

How long should choosing a software development company take?

For most projects, two to six weeks from first contact to signed contract is realistic. That allows time for calls, references, a proposal and a contract review without letting the project stall.

Put these questions to us

The right software development company will welcome these questions, because good answers are how it wins work. The wrong one will try to steer the conversation back to its portfolio.

Krispire builds bespoke software, ERP systems and SaaS platforms for businesses in the UK and Europe. You can see the kind of work we do in our case studies, and if you are drawing up a shortlist, we are happy to answer all 12 questions for your project.

Talk to our team about your project

This article is general guidance, not legal advice. Have a solicitor review any software development contract before you sign it.