How to choose a software development company: the short answer
To choose a software development company, shortlist three to five whose live work you can open and check. Then ask each one the same three questions in writing: who owns the code and the accounts, who you'll talk to, and what's in the scope. Pick the company whose answers are specific enough to go straight into the contract.
This guide is for founders and operations leads at UK and EU companies of 10 to 200 people who are about to commission custom software. Most advice on choosing a development partner tells you to check the portfolio, the reviews and the tech stack. Those checks matter. They're also the ones every company prepares for.
The three questions here are harder to prepare for, because a vague answer shows. One of them has a legal edge: under UK law, paying for the code doesn't make it yours.
We're a software studio, so we have an interest. We've written the guide we'd want a client to use on anyone, us included. It ends with the cases where you don't need a software development company at all.
What most checklists cover, and the gap they leave
The usual advice is sound as far as it goes. Look at the portfolio, read the reviews on Clutch or Google, and check the company knows your technology. Notice how fast it replies, and ask about its process. Do all of it.
Those checks answer one question: can this company build software? They don't answer the questions that decide how the next two years feel.
Who holds the keys if the relationship ends? Who picks up when something breaks? What did you actually agree to buy?
When you commission software, you usually can't judge the work itself. You can't read the code in a sales meeting, and a demo that looks finished tells you little about the second release. A company can win that meeting on impressiveness alone.
What you can judge is whether an answer is specific, and whether the company will put it in writing. Ownership, access and scope are three questions where that test works, even for a buyer who has never written a line of code.
If you already have proposals on the table and want a second opinion, that's what our software consulting is for. You get a written recommendation you can act on with or without us.
Question 1: who will own the code, the accounts and the documentation?
Ask who will own each part of the project, and when each part moves to you. That means the copyright in the code, the domain, the hosting, the code repository, the documentation and every paid service the system depends on.
Under UK law, ownership starts with the supplier. The Copyright, Designs and Patents Act 1988 makes the author of a work its first owner, and an employer owns what its staff write at work. So the agency owns the code its developers write. Section 90(3) says an assignment of copyright takes effect only in writing, signed by the owner, so paying the invoice transfers nothing.
The UK government doesn't leave this to chance when it buys technology. Its guidance on defining a purchasing strategy, part of the Technology Code of Practice, tells government teams to be explicit about who owns the intellectual property in a service. It names software code and business rules, and asks the same for data. If the government writes that into its own buying rules, a 30-person company can ask for it too.
A clear answer points to a clause that assigns copyright to your company. It says each account will sit in your company's name and gives a date for each move. Worry when you hear "you'll own it once it's paid for" with no clause behind it, or "it all runs on our platform".
Some agencies reuse their own components across clients and license them instead of assigning them. That can be fair, if the licence is permanent and lets another developer change the code. Get the terms in writing either way, and have a solicitor read the contract before you sign.
Our guide to checking whether you own your website has five checks that work for any software, and most need nothing from the supplier.
Question 2: who will we talk to, and who will write the code?
Ask for the names of the people who will build your project, and whether you can speak to them directly. Then ask whether any of the work goes to freelancers or another company, and where they are based.
A sales meeting shows you the people who sell. Ask to meet the people who build. Every message that passes through an account manager loses some detail on its way to the engineer. The engineer's questions lose more on the way back.
The authors of the Agile Manifesto made the fix one of their twelve principles. Business people and developers, it says, "must work together daily throughout the project".
The subcontractor question has a legal edge too. If the company will handle personal data for you, Article 28(2) of the GDPR requires your prior written authorisation before it brings in another processor. A subcontractor you've never heard of is a data protection problem as well as a quality one.
A clear answer gives you names, offers a call with the engineer before you sign, and lists any subcontractors. Worry when every answer routes back to "your account manager will handle that". Worry too when a question about who writes the code gets a description of the company's network of partners.
Question 3: what exactly is in the written scope?
Ask for the scope in writing before you sign, and read it for what it leaves out. A useful written scope covers:
- What will be built, feature by feature or screen by screen.
- What won't be built, stated plainly.
- The assumptions, such as who supplies the content and which systems it connects to.
- What "done" means for each part, and who tests it.
- How a change gets priced and agreed in writing before anyone starts on it.
- What you receive at handover.
Agile is a way of working, and a good one. It doesn't replace writing down what you're buying. An agile team still writes down each piece of work before it starts.
Then ask how the company reached its timeline. It's the question that separates a plan from a promise.
In BSkyB v EDS, a 2010 High Court case over a customer relationship management system, part of Sky's claim turned on the sales pitch. The judge found that the head of EDS's CRM business had put forward delivery timescales he knew had no proper basis, to win the contract. The court held that this was fraudulent misrepresentation. Pinsent Masons' guide to the case sets out the findings.
Few pitches go that far. The lesson for a buyer is simpler: a timeline without workings is a guess. Ask for the assumptions behind it, and which parts the company is least sure of. A timeline that lands exactly on the date you asked for deserves the same question.
How to compare the answers side by side
Send every company on your shortlist the same questions in the same email, then put the replies in one table. The differences then come from the companies, not from how each conversation went. Add two follow-ups: how each company reached its timeline, and what it would leave out.
| Question | A clear answer | An answer to worry about |
|---|---|---|
| Who will own the code? | A named clause assigning copyright to your company | "You'll own it once it's paid for", with no clause |
| Whose name is on the accounts? | Your company's name on every account, with a date for each move | "It's easier if it stays on our platform" |
| Who will we talk to? | Named engineers, and a call with one before you sign | An account manager for everything |
| Who writes the code? | The named team, plus any subcontractors listed | "Our network of partners" |
| What's in the scope? | A document listing what's in, what's out and how changes are agreed | "We're agile, we'll work it out as we go" |
| How did you reach the timeline? | The assumptions, and the parts they're least sure of | A date with no workings |
| What would you leave out? | Something specific, with a reason | "Everything on your list is doable" |
How a company writes before you sign is the best preview you'll get of its weekly updates after. Our list of questions to ask before you hire a software developer covers testing and support too, with what a good answer sounds like.
Three more checks before you sign
Ask what they would leave out
Ask each company which parts of your list it would cut or delay, and why. The Agile Manifesto counts simplicity, which it defines as maximising the work not done, among its principles.
A company that shortens your list gives up revenue to do it. You may not be able to judge its technical calls, but you can tell when it has talked you out of spending money. That's a signal a polished demo can't fake.
Check the company on its register
For a UK company, Companies House shows the directors, the filing history and any insolvency information, free. For a company abroad, use its national business register. Our guide to working with a software studio in Albania shows how to do this for Albania. It also covers the data and contract points that change across a border.
Start with a small, paid first phase
Try a short first phase, such as an audit, a discovery phase or a first release. It shows you how a company writes and delivers before you commit to the whole build. When we take over an existing codebase, we start with an audit and a written recommendation. It includes the case for rebuilding, when that's the better path.
How we answer the same questions
Every company should be able to answer these in writing, and that includes us. Here are our answers, taken from how we already work.
On ownership, you own it. Your domain, hosting, code repository and documentation sit in your accounts. We build on our own infrastructure while the work is under way, then transfer everything at handover. The code and the content are yours outright, and our name appears as the studio that built it.
On access, you talk to the engineers writing the code. There's no account manager in between, and you hear back within one business day.
On scope, you get a written scope before work starts and a written update every week. A shared staging environment, a private copy of the system, lets you click through what's built so far.
Each of our case studies links to the live site, so you can check the work yourself. KOP44, a flooring and wall covering contractor in Nantes, has a site we wrote and built in French. It gives seven service lines their own pages and sends quote requests to one point of contact instead of a general inbox. ES Construction, a residential builder in London, has nine service lines and quote routing by phone, email or WhatsApp.
The ES Construction page explains why WhatsApp sits level with the phone number: for a builder, it's often the first contact. Look for reasons like that in anyone's case studies. A company that made a decision can tell you why. If a case study shows screenshots and no reasons, ask for them.
When you don't need a software development company
Sometimes the right answer is not to hire one, or not yet.
- A product you can buy already does most of the job, and you can adjust your process to fit the rest. Our comparison of custom software and off-the-shelf tools covers when building your own pays off.
- The job is small and well defined, such as one change to one feature. A good freelancer may fit better. If software is your product and will need work every week for years, an in-house team may fit better still. Our guide to choosing a software agency, a freelancer or an in-house developer sets out the trade-offs.
- Nobody on your side can spend a few hours a week reading updates, answering questions and testing on staging. No company can fix that.
- Your current supplier already passes these three questions, and the work is a change to what it built. Switching would cost more than it saves.
If none of these applies, write the three questions into one email this week. Send the same email to every company on your shortlist and put the replies side by side. The company that answers with names, clauses and dates is showing you how it will run your project.
Questions
Should we sign an NDA before we describe the project?
Sign one before you share anything that would hurt you in a competitor's hands. Customer data, your pricing model or a process that sets you apart all count. A general description of what you need rarely carries that risk. Once you hire someone, put a confidentiality clause in the main contract so the whole project is covered, not only the first conversation.
How many companies should we ask for proposals?
Three to five. With fewer, you have nothing to compare. With more, you won't read the answers properly, and the good companies will notice a brief sent to a crowd. Send every company the same brief and the same questions, so the differences you see come from the companies.
Is the lowest quote a warning sign?
Not by itself. List what each quote includes: testing, documentation, the handover, the accounts in your name, and support after launch. A lower quote that leaves out the handover or the documentation costs you later, when you want to change supplier or bring the work in-house. Compare the lists, then the totals.
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.