Skip to content
TrustList
Blog

How to choose a software development company: the 2026 buyer's guide

Editorial

By TrustList Editorial

How to brief a software development company, what to check before you sign, and the contract terms on code ownership, personal data and security that protect you.

About How to choose a software development company: the 2026 buyer's guide

How to choose a software development company: the 2026 buyer's guide

Commissioning custom software is not like buying a product. Nothing exists yet. You are choosing the people who will design and build it, and the way they will work with you, often for months. That choice decides more than what gets built. It decides whether you own the result, whether it is secure, and whether anyone else can maintain it once the first firm has moved on.

This guide is for UK, European and US organisations commissioning bespoke software, such as a customer portal, an internal system or the first version of a new product. It covers engagement models, how to brief firms, what to check before you sign, what the contract should say about ownership, data and security, the warning signs, how to compare proposals, and how to use TrustList's software development rankings to build a shortlist.

You will not find day rates, project costs or "percentage of projects that fail" figures here. They vary widely with scope, seniority and location, and we have not found public figures we can verify to the standard we apply. Where we refer to a standard or to official guidance, the publisher is listed under Sources at the end.

What a software development company does, and how it sells the work

Firms use many labels: software house, development agency, product studio, consultancy. The labels matter less than the engagement model, because the model decides who manages the work and who carries the risk when plans change.

Three common engagement models

Project delivery. The firm designs, builds and hands over a defined system, and may host and support it afterwards. You agree the outcome and the firm decides how to staff it. This suits work with a clear boundary, such as replacing an old system.

A managed product team. The firm provides a team, usually a mix of product, design, engineering and testing, that works through your roadmap under the firm's delivery management. This suits a product that will keep changing.

Staff augmentation. Individual developers join your own team and work under your technical leads. The firm employs them and you direct the work, so it only works if you already have engineering leadership. If that is what you need, see the ranking of offshore staff augmentation firms.

Fixed price, time and materials, and hybrids

Under a fixed price, the firm commits to a defined scope for an agreed sum. It takes on the risk of underestimating and prices that in, and any change becomes a formal change request. Fixed price works when the scope is genuinely known. When it is not, the conversation moves from "what should we build?" to "what did the contract say?".

Under time and materials, you pay for the time spent. You keep the freedom to change direction, and you carry the risk if the work takes longer. It needs someone on your side who can set priorities every week.

Many buyers use a hybrid: a short, fixed-price discovery phase, then delivery on time and materials with a budget reviewed at the end of each phase.

Why a paid discovery phase is worth considering

The GOV.UK Service Manual, written for public sector teams but useful to any buyer, describes a discovery phase for understanding the problem before committing to build. It is clear that stopping is a valid outcome: "It's not a failure to stop at the end of the discovery phase if your research shows that's the best thing to do." The alpha phase that follows is for trying out solutions, and the manual says a crucial part of it is "identifying your riskiest assumptions and testing them".

A paid discovery lets you judge a firm before the large commitment, and gives it enough understanding to estimate honestly. Agree in writing that you own what it produces, so you can take the findings elsewhere.

How to scope and brief a software project

A good brief does two jobs. It helps firms propose something sensible, and it makes their proposals comparable.

Describe the problem before the solution

Start with who will use the software, what they need to get done and what happens today. Describe what success would look like in your own terms, such as fewer manual steps, faster processing or a report nobody has to assemble by hand. A feature list written before that thinking fixes a solution too early, and firms will price the list rather than the problem.

What to include

  • Users and journeys. Who uses it, for what, how often and on which devices.
  • What exists. Current systems, data and integrations, and who owns each one.
  • Constraints. Deadlines tied to real events, technology standards you use, and regulatory requirements.
  • Personal data. What personal data the system will hold, and whether any of it is sensitive.
  • Security. The level of assurance you need. The OWASP standard covered below gives you a precise way to state it.
  • Accessibility. The standard the software must meet, normally WCAG 2.2 at level AA.
  • After launch. Who will host, support and further develop the system.
  • Your side. Who will act as product owner, and how much time they really have.
  • Budget. A range, and how decisions about scope and budget will be made.

Buyers often hold back the budget in the hope of a lower quote. Firms then guess, and you receive proposals for very different products that cannot be compared. A range lets each firm show what it would do within it and what it would leave out.

What to check and ask before you sign

The company

Check the firm on its official company register, such as Companies House in the UK, and confirm that the registered name matches the proposal, the contract and the bank account you will pay. Ask what professional indemnity and cyber insurance it holds. Speak to clients whose projects resemble yours rather than relying on written testimonials.

The team you will actually get

Ask for the names, roles and experience of the people who would do the work, and how much of their time each will give your project. Meet the technical lead before you sign. Ask whether any work will be subcontracted, and where the people doing it are based.

How they build software

Ask questions that make the firm describe its real practice rather than its values:

  • How often will we see working software, and can we use it in a test environment?
  • How do you handle a change in requirements? Can you show us an anonymised change request?
  • How are code reviews done, and what automated tests do you write?
  • How do you release a new version, and how do you roll one back?
  • Could another firm maintain the system from the documentation you hand over?
  • How do you track the licences and known vulnerabilities of open-source components?
  • Will you give us a software bill of materials? The US Cybersecurity and Infrastructure Security Agency describes an SBOM as "a nested inventory, a list of ingredients that make up software components".

Security practice

Three free, public references help you ask precise security questions.

The OWASP Top 10, now in its 2025 edition, is OWASP's reference list of the most critical web application security risks. Its first category is broken access control, and the 2025 list includes software supply chain failures. Ask each firm how its process guards against these risks, and listen for specifics rather than reassurance.

The OWASP Application Security Verification Standard (ASVS), currently version 5.0.0, turns security into requirements. One of its stated purposes is to "provide a basis for specifying application security verification requirements in contracts". It has three levels, each building on the one below, and says of Level 2: "Most applications should be striving to achieve this level of security." Choose a level based on how sensitive the system is, write it into the brief, and ask how the firm would show that the software meets it.

The NIST Secure Software Development Framework (SP 800-218) sets out secure development practices, and NIST notes that purchasers can use it "to foster communications with suppliers in acquisition processes". For higher-risk systems, ask a firm to show how its process maps to it.

Be careful with badges. OWASP states that it "does not certify any vendors, verifiers, or software", so "ASVS certified" is not an OWASP certification. In the UK, the National Cyber Security Centre describes Cyber Essentials as the minimum standard of cyber security the government recommends, and Cyber Essentials Plus adds independent technical testing; current certificates can be looked up through the scheme's official search. If a firm cites ISO/IEC 27001, ask for the certificate and check that its scope covers the service you are buying.

Contracts: ownership, data protection and security

Take legal advice on the contract. These are the points most often left vague.

Make sure you own the code

In the UK, paying for work does not automatically make you the owner of it. The Intellectual Property Office explains that the first owner of copyright in commissioned work is "the person or organisation that created the work and not you the commissioner", unless you agree otherwise in writing. Other countries have different rules, so take advice under the law that governs your contract.

Your contract should therefore:

  • assign to you the intellectual property (IP) in everything written for you, with confirmation that the firm holds those rights from its own staff and subcontractors;
  • give you a permanent, royalty-free licence to any pre-existing code or tools the firm keeps, broad enough for another firm to maintain the system;
  • list the open-source components used and their licences;
  • avoid making ownership depend on the final payment for the whole project, which leaves you exposed in any dispute. Assignment as each milestone is paid is a common compromise.

Keep control in practice as well as on paper. The code repository, hosting accounts, domain names and third-party service accounts should be in your organisation's name from the first day, with the firm given access.

Personal data

If the firm will handle personal data on your behalf, it is likely to act as your processor, and UK GDPR requires a contract with specific terms. The ICO lists them: the processor acts only on your documented instructions, binds its people to confidentiality, keeps the data secure, uses sub-processors only with your authorisation, helps you with rights requests and breaches, deletes or returns the data at the end, and allows audits. The ICO notes that this guidance is under review following the Data (Use and Access) Act 2025, so check the current version.

The ICO also says the data protection by design requirements "don't apply directly to processors", so the duty to build privacy in stays with you. If the firm's staff are outside the UK and can access personal data, that is likely to be a restricted transfer, needing a safeguard such as the International Data Transfer Agreement and a transfer risk assessment. Often the simplest protection is to keep real personal data out of development and test environments.

Security, accessibility and quality in writing

Put the non-functional requirements into the contract, not just the brief:

  • the ASVS level the software must meet, and an independent security test before go-live;
  • who fixes the vulnerabilities that testing finds, how quickly and at whose cost;
  • conformance with WCAG 2.2 at level AA. The W3C notes that content meeting WCAG 2.2 also meets 2.1 and 2.0, and that WCAG can be applied to non-web software such as native apps;
  • acceptance criteria, and an acceptance testing period for each release.

Support, warranty and exit

Agree a warranty period for fixing defects without charge, the terms of ongoing support, and how third-party components will be kept patched. Then plan the exit on day one: what the firm must hand over, including code, documentation, credentials and infrastructure configuration, how it will help with a move to another supplier, and how either side can end the contract.

Red flags when choosing a software development company

  • A fixed price before any real questions. A firm that prices a complex system from a two-page brief has added a large contingency or will argue about scope later.
  • An estimate that lands exactly on your budget, with no trade-offs described.
  • No named team, only senior people at the pitch.
  • Code kept in the firm's own repository, with access promised only at the end.
  • Vague IP terms, or a licence where you expected ownership.
  • Testing "at the end", or no automated tests at all.
  • Security answered with adjectives, or with certification claims you cannot check.
  • Pressure to sign quickly, such as a discount that expires this week.
  • Large upfront payments that are not tied to delivered milestones.
  • A proprietary platform you would be locked into, mentioned late or not at all.

How to compare proposals fairly

Give every firm the same brief, the same access to your team and the same answers. If one firm asks a good question, share the answer with all of them.

Before you open any proposals, agree the criteria and how much each counts. Typical criteria are understanding of the problem, the approach, the team, security and quality practice, the commercial terms and how well you expect to work together.

Then make the proposals comparable:

  • Map the scope line by line. Mark whether each proposal includes, excludes or ignores each item in your brief.
  • Read the assumptions. A lower price often assumes your team supplies designs, content or test data.
  • Compare the team, not only the total. Look at roles, seniority and time allocated.
  • Credit the risks a firm raises. Pointing out problems you had not noticed shows understanding.
  • Look at the cost of ownership. Hosting, licences, support and later changes can outweigh differences in the build price.

For a large project, consider paying your top two firms for a short discovery. It will tell you more than another round of presentations.

How to use TrustList to build a shortlist

As of September 2026, 5,566 firms on TrustList list software development among their services, 1,208 list custom software development and 11,564 list web development. The software development rankings cover 2,856 companies, split into rankings by service and by location, so you can start from the one closest to what you are buying.

How the rankings work. Rankings are ordered mainly by client reviews and by how complete a firm's profile is, with a smaller lift for verification and other trust signals. Few firms have reviews on TrustList yet, so do not read a position as a verdict from clients. Our trust and methodology page explains how reviews are checked and how rankings stay independent. Sponsored placements are labelled, and payment never changes the organic order.

What the Verified badge tells you. Firms that pass TrustList vetting have had their registration and website checked, and a client or clear published evidence has confirmed that they deliver what they sell, with no insolvency or regulatory action found. The badge tells you a firm is real and active, not whether it suits your project.

A practical route to a shortlist:

  1. Open the ranking closest to your need and read the profiles of firms that describe work similar to yours.
  2. Put up to four side by side with compare.
  3. Contact three or four firms from their listings, or post a request describing your project. An open request is published to the requests board so that matching firms can respond, so keep confidential details out of it and share them once an NDA is in place.
  4. Put the firms that respond well through the checks and questions in this guide.

A ranking can narrow the field. Only your own conversations, reference calls and, ideally, a paid discovery phase can show whether a firm is right for your project. TrustList's rankings are not for sale.

Sources

Categories & features

Keep exploring

More on TrustList

Everything here links back to the same verified catalogue. Pick your next stop.