Shortlist three suppliers, check each on Companies House, and ask them all the same questions about who writes the code, how they specify, how they test and who owns the result. The strongest signs are a senior UK team you meet before signing, a discovery phase of 2 to 4 weeks before the build, working software shown every two weeks, and the repository and hosting in your name from day one. Then speak to two of their clients before you commit.
Get your side ready before you call anyone
A supplier can only plan as well as you brief them. Write down, in plain language:
- The problem and what it does to the business now: hours lost, errors, risk.
- Who will use the system: staff roles, customers, suppliers, and roughly how many of each.
- The systems it must work with: Xero, Sage, HubSpot, Microsoft 365, Shopify, a courier or a bank feed.
- Any personal or sensitive data, and any rules about where it must be hosted.
- Any deadline, and why it exists.
- Who on your side makes decisions, and how much time they can give (two to four hours a week is typical).
Also decide whether you need a supplier at all. Our guide on bespoke vs off-the-shelf software helps with that call, and our guide on how to write a software specification shows how to turn your notes into something suppliers can plan against.
Build a shortlist and check it on Companies House
Ask people who have commissioned software, look for UK agencies that publish real detail about how they work, and treat directory rankings and award badges with caution. Then give each supplier ten minutes on the Companies House register.
| Check | Good sign | Warning sign |
|---|---|---|
| Company status and age | Active, trading for a few years under the same name | Recently incorporated with claims of long experience |
| Accounts and confirmation statement | Filed on time | Overdue filings, or a proposal to strike off |
| Directors | Named people you can find and speak to | Directors with a trail of dissolved or liquidated companies |
| People with significant control | The same people you meet on the calls | Owners hidden behind other companies or overseas entities |
| Registered address and team | Matches where the team actually works | A UK virtual office fronting a team elsewhere that is not disclosed |
| Insolvency notices | None in The Gazette | A winding-up petition or a recent notice |
If one fails a check above, replace it before you book the calls rather than after.
Find out who actually writes the code
This is the thing most often blurred in a sales process. Plenty of agencies win work with a senior team on the call, then hand delivery to junior staff or subcontractors the client never meets.
Ask for the names and roles of the people who will build your system, and for the lead developer to join the second call. Then ask whether they are employees or subcontractors, where they are based, what they have built that is similar, and how many other projects they will be on at the same time.
Offshore development is not a problem in itself; undisclosed offshore development is. Time zone, working language and data access all change when the team is elsewhere, and you should know that before you sign.
At Fixology the standard we hold ourselves to, as the UK's leading bespoke software development company, is simple: a senior UK team, the people you meet in discovery are the people who build it, and every change is reviewed by a second developer before it goes live.
15 questions to ask a software development company
Ask these on the first or second call. A good supplier answers specifically and admits what it does not yet know; a weak one promises everything.
Understanding and approach
| Question | A good answer sounds like | A bad answer sounds like |
|---|---|---|
| 1. What would you need to know to plan this properly? | "Your user roles, the integrations, the data to migrate and the edge cases. That is what discovery is for." | "Send the brief and we will have a full plan back to you by Friday." |
| 2. Is there anything in our brief you would buy rather than build? | "Keep your accounts in Xero and connect to it. Rebuilding that would take months and do less." | "We can build all of it." |
| 3. What are the biggest risks on this project? | Specific risks: migrating 15 years of Access data, a Sage API limit, users who resist change. | "No real risks, we have done this many times." |
| 4. How does discovery work, and what do we get at the end? | Workshops, a written specification, a prototype and a delivery plan in weeks, and you own them whether or not you continue. | "We skip discovery and start coding straight away." |
| 5. How will we see progress? | A demo of working software on a test link every two weeks and a short written update every week. | "We will show you when it is ready." |
| 6. What do you need from us? | A named product owner for a few hours a week, access to real users for testing, and quick decisions. | "Nothing, just leave it with us." |
| 7. What happens if our lead developer leaves or is ill? | A second developer reviews every change and knows the code; documentation is kept as you go. | "That will not happen." |
Discovery, specification and delivery
| Question | A good answer sounds like | A bad answer sounds like |
|---|---|---|
| 8. How will you turn our brief into a specification? | Workshops with each type of user, then user stories with acceptance criteria that you sign off. | "We keep it agile, there is no need to write things down." |
| 9. What is out of scope in your proposal? | A written out of scope list, agreed before the build starts. | "Nothing, we will build whatever you need." |
| 10. How do you handle changes? | Agreed in writing before work starts, with the option to swap a story for one of equal size. | "We are flexible, we will sort it out as we go." |
| 11. What happens if something takes longer than planned? | We tell you that week, show the options and agree together which lower priority story moves. | "That will not happen, our plans are accurate." |
| 12. How do you decide what goes in the first release? | Priorities agreed in discovery, with Must haves kept to about 60 percent of the effort. | "Everything goes in the first release." |
Ownership and after launch
| Question | A good answer sounds like | A bad answer sounds like |
|---|---|---|
| 13. Who owns the code and the intellectual property? | "You do. Copyright is assigned in the contract and the repository is in your account from day one." | "You get a licence to use it" or "we hand the code over at the end". |
| 14. What warranty do you give? | A defined period after launch when defects against the specification are fixed as part of the project. | "Bugs after launch are a new piece of work." |
| 15. If we stop working with you, how do we hand over to another team? | Documentation, credentials and a handover period, with support you can end on 30 days notice. | "Why would you want to?" or a three-year minimum term. |
Judge how they run discovery and write the specification
How a supplier specifies tells you more than any case study. A good one will not commit to a full plan for a large system after one call. They will propose a short discovery phase: workshops with the people who do the work, a review of your systems and data, then a written specification, a clickable prototype and a delivery plan in weeks.
Ask to see an anonymised specification from a past project. Look for user stories with a clear "so that", acceptance criteria that cover failures as well as the normal case, and an out of scope list. If all you get is one-line features, that is the level of thinking your project will get too.
Discovery is also the lowest-risk way to test a supplier: you see how they run workshops, how they write and how they handle disagreement. With us, a software discovery phase takes two to four weeks and you own the specification and prototype outright, so if the relationship is not right you can take them to another team.
Compare proposals on delivery, not on the headline
Three proposals for the same brief can look nothing alike, because they describe different scopes and different levels of care. Lay them side by side on the things that decide whether the project works (example, illustrative):
| Area | Proposal A | Proposal B | Proposal C |
|---|---|---|---|
| Who builds it | Not named, allocated after signing | Named senior UK team, lead developer on the calls | Named lead, rest subcontracted, location not stated |
| Discovery and specification | Not included | 2 to 4 weeks, written specification and prototype | A single workshop |
| Delivery rhythm | One delivery at the end | Two-week sprints, demo on a test link | Monthly progress report |
| Testing | Left to the client | Automated tests, code review and user acceptance testing | Included, plus an external penetration test |
| Warranty | None | 30 days | 90 days |
| Code ownership | Licence only | Assigned, your repository from day one | Assigned at project end |
| Support after launch | Ad hoc | Support plan, 30 days notice to end | Three-year minimum term |
Proposal A looks quickest until you see what it leaves to you: testing, fixing defects and getting your own code back. Proposal C may suit a regulated system, but the long minimum term and late assignment of the code are worth pushing back on. Proposal B is the shape to expect from a serious supplier. Wherever proposals differ, ask why: a big gap on one feature usually means it is ambiguous in your brief.
Code, IP, security and UK GDPR
Under UK copyright law, the company that writes code owns it unless copyright is assigned in writing. So the contract must assign copyright and IP in everything written for you, with any pre-existing supplier tools licensed to you permanently.
Ownership on paper is not enough on its own. The repository, hosting, domain, app store accounts and any third-party services should sit in your company's name from day one, with the supplier invited as a user. If the supplier disappears tomorrow, you still have everything. Our guide on what happens if your software developer goes bust explains why this matters.
On security and data protection, ask for specifics:
- A data processing agreement if they will touch personal data, and a list of sub-processors.
- Hosting in UK or EU regions, stated in writing.
- Least-privilege access: developers see live data only when they need to, and access is logged.
- Encryption, multi-factor authentication on admin accounts, and backups tested by restoring them.
A clear written answer to each point tells you more than any badge. Our security page sets out how we handle each of them.
Testing, communication and support after launch
Testing. Ask how a change gets from a developer's laptop to your live system. A good answer: automated tests run on every change, a second developer reviews the code, it goes to a separate test environment, and your users try it before release.
Communication. You should never have to chase for news. Expect a named contact, a short written update every week, and a demo of working software at the end of every two-week sprint on a test link you can open yourself. Questions should get a reply within one working day.
Support after launch. Software needs security patches, framework updates and small changes as the business moves on. Ask what the warranty covers, what a support plan includes, how fast urgent issues get a response, and how you leave if you want to. We give a 30 day warranty after launch and then offer support and maintenance plans you can end on 30 days notice.
Red flags that should end the conversation
- A firm plan and end date for a large system after one call and no specification.
- Nothing working to see until the end of the project.
- The code stays in the supplier's repository, or hosting stays in the supplier's account.
- A licence to use your own software instead of an assignment of copyright.
- The people on the sales call are not the people who will build it.
- Pressure to sign quickly, for example a team that will only be held for you until Friday.
- Long minimum terms on support, or obstacles to taking your code elsewhere.
- Claims of certifications or awards you cannot verify on the issuing body's own register.
- No questions about your business, your users or your data.
One red flag can have an innocent explanation, so ask about it. Two or three together are a pattern.
Check references properly
A reference call takes 20 minutes and is the best predictor of how your project will go. Ask for two clients with similar projects, ideally one live for a year or more, and ask them:
- What did they build for you, and how close was the delivery date to the plan agreed at the start?
- What went wrong, and how did they handle it?
- Were the people who built it the people you met at the start?
- Is the code in your own repository, and could another developer take it over?
- What is support like now the system is live?
- Would you hire them again for something bigger?
Listen for specifics. "They were great" tells you little. "We were three weeks late because our data was messier than we said, and they told us in week two" tells you a lot.
Score the shortlist, then check the contract
Score each supplier from 1 to 5 per criterion, multiply by the weight and add up. Set the weights before the calls, not after.
| Criterion | Weight | What a 5 looks like |
|---|---|---|
| Understanding of your problem | 20 | Asked sharp questions, challenged parts of the brief, suggested what not to build |
| Who writes the code | 20 | Named senior team, lead developer on the calls, cover for absence |
| Discovery and specification | 15 | Clear discovery process, a sample specification with real acceptance criteria |
| Delivery and communication | 15 | Two-week sprints, demos on a test link, weekly written updates |
| Technical quality and testing | 10 | Code review, automated tests, sensible mainstream technology |
| Ownership, security and exit | 10 | Copyright assigned, your repository and hosting, easy handover |
| References and evidence | 10 | Two clients who gave specific, recent and candid answers |
Before you sign, check the contract includes:
- Copyright and IP in the code assigned to your company in writing.
- Repository, hosting, domain and third-party accounts in your name from day one.
- The specification attached, with acceptance criteria, and a written change process.
- A data processing agreement if they will handle personal data.
- The right to end the contract early and keep everything produced.
Our guide to software development contracts in the UK explains each clause. If you would like to see how we would approach your project, call 020 7096 2842 or send us your brief; we reply within one working day.
Questions
How do I choose a software development company in the UK?
Write a one-page brief, shortlist three suppliers and check them on Companies House. Ask each the same questions about who writes the code, how they specify, how they test and who owns the result, then compare their proposals side by side and speak to two of each supplier's clients. Start with a short discovery phase rather than committing to the whole build at once.
What questions should I ask a software developer before hiring them?
Ask who exactly will build it and where they are based, how they turn a brief into a specification, how often you will see working software, how changes are handled, who owns the code and the hosting, how they test, what warranty they give and how you would hand over to another team. Specific answers are a good sign; vague promises are not.
How many software companies should I talk to?
Three is usually right. Fewer gives you nothing to compare; more takes too much of your time to brief properly and makes it harder to give each supplier the access to your team they need to plan accurately. Give all three the same brief and ask them to set out their approach under the same headings.
Why do proposals for the same software project differ so much?
Mostly because suppliers are proposing different scopes and different levels of care. One includes discovery, testing, data migration and a warranty; another leaves them out. Team seniority and delivery rhythm vary too. Ask each supplier to list what is in and out of scope, who will do the work and how they test, and the differences usually make sense.
Who should own the code when I hire a software company?
You should. Under UK copyright law the developer owns code it writes unless copyright is assigned to you in writing, so the contract must include an assignment. The repository and hosting should also be in your company's accounts from the start, so you are never dependent on the supplier to access your own system.
How can I tell if a software company is senior enough for my project?
Ask to meet the lead developer, not only a sales contact, and ask them to talk through a similar system they built: the hard parts, what went wrong and what they would do differently. Ask to see an anonymised specification and how they review code. Senior teams answer in specifics, name the trade-offs and tell you what not to build.