01 — The short answer
What is the best custom software development company in the UK for small businesses?
The best fit is a company that can show how it will solve your particular problem, who will do the work, what you are paying for and how the system will be supported. A large team or a familiar name does not answer those questions on its own.
Start with evidence from a comparable project, a conversation with the people responsible for delivery and a proposal you can understand. For business systems, look closely at integrations, data migration and the day-to-day work of the people using the software.
We are Launched, a Bradford-based development company working with businesses across the UK. This is our perspective as a team that builds custom software and connects business systems. These are questions we think buyers should ask us as well as other developers.
02 — The decision before the supplier
Check whether you need custom software at all.
A developer should be able to discuss an existing product, a connection between your current tools and a custom build. Sometimes the sensible project is keeping most of what you already have and fixing one awkward part.
If staff copy customer details from a CRM into an accounting system, investigate whether those systems can exchange the information. You may need an integration rather than a replacement for either product. If the missing piece is a process specific to your business, a custom tool may be justified.
Ask the company to explain what it would keep, what it would change and why. The explanation should make sense in terms of the work and ongoing cost. You should not need to understand a particular programming framework to follow it.
Still choosing your underlying tools? Our CRM, data and automation guide explains the limits and integration options to check first.
03 — The people doing the work
Compare the delivery team, not the headcount.
A freelancer, a small development company and a larger agency can each be a suitable choice. What matters is the team assigned to your project, the skills available to it and how responsibility is shared.
A small team may give you close access to the people making technical decisions; ask how it covers absences and specialist work. A larger agency may have more disciplines available; ask which of those people are actually included in your budget and how you will speak to them. Neither arrangement is automatically better.
In an initial conversation, ask who will lead the work, who will build and review it, and who you contact when a decision is needed. Check how your own staff will be involved. Someone in your business needs time to answer questions and try the system before launch.
Relevant experience helps, but it does not have to mean an identical client or software stack. Ask the team to explain a similar problem, the constraints they found and what they learned. For an unfamiliar API, ask how they would establish whether it can do what your project needs.
04 — Before the build
Look for questions about the work, not just the website or app.
Walk through a real task together. An enquiry arrives: who checks it, where does it go, what information is missing, and what happens when the customer changes their mind? The exceptions often tell you more than the ideal sequence.
For an integration, the team should investigate the data each system can read and change, access permissions, usage limits and how records will be matched. A successful connection in a demo is not the same as a dependable process with real customer data.
Discovery can be a short investigation or a separate paid phase. Its scale should match the uncertainty. Ask what you will have at the end: a proposed first release, tested assumptions, a data plan, open questions and enough information to decide whether to proceed.
You should also understand where decisions and progress will be recorded. Working previews, clear review points and a shared project record make it easier to catch misunderstandings while there is still time to change the work.
05 — Scope and price
Compare what the quotes actually include.
A lower total may cover less work. One proposal might include migration, testing with your staff and launch support; another might price only the application. Get the differences onto the page before deciding which offers better value.
For a project you are budgeting £20,000–£30,000 for, define the first useful release and the work needed to get it into daily use. That is an example buying budget, not a market price or a Launched quote. The scope and the unknowns determine whether a particular budget is realistic.
“Connect our CRM and accounts” leaves a lot unanswered.
- First release
- Create a draft invoice when a sale is approved, using agreed customer details and line items. A member of staff reviews it before sending.
- Checks
- Missing details go back for review. Repeating the transfer must not create a second invoice. Failed transfers are visible to the responsible person.
- Assumptions
- The accounting API supports the required action, appropriate access is available, and a test environment or safe test process can be agreed.
- Outside this release
- Historical data migration, payment reconciliation and automatic invoice sending are separately scoped.
- Acceptance
- Sales and accounts staff try agreed examples, including missing information, duplicates and a failed connection.
Ask for one-off and ongoing costs separately. Hosting, paid software, usage charges and maintenance can remain after the build is paid for. Check which accounts your business will hold and who handles changes to a connected service.
A fixed price can work well for a defined scope. Time-based or phased work can suit a project with genuine unknowns. In either case, agree how spending is controlled, when you review progress and how changes affect the price and timing. A fixed-price label does not resolve an unclear brief.
06 — Take this into the conversation
Eight questions to put beside every proposal.
Ask each team the same questions and keep the answers together. A missing answer is a reason to clarify the proposal before committing, rather than an automatic reason to reject it.
Download the proposal checklist (.txt)What will the first release let our team do?
Look for: Specific users, tasks and acceptance criteria, with later phases and exclusions separated.
Who is responsible for delivery?
Look for: The people building and reviewing the work, your day-to-day contact, and cover when someone is unavailable.
What still needs investigating?
Look for: Named assumptions about APIs, data, permissions or third parties, with a plan to resolve them.
What does the price include?
Look for: Discovery, design, development, migration, testing, launch and handover; payment stages and any usage or licence costs.
How will we see progress and approve changes?
Look for: Working previews, a shared record of decisions, review responsibilities and the effect of changes on cost and timing.
How will we know it works?
Look for: Agreed business scenarios, user testing, permissions checks and tests for failed or repeated requests.
What will we own and have access to?
Look for: Source code, hosting, accounts, data and documentation, including any third-party licence restrictions.
What happens after launch?
Look for: Aftercare and ongoing support scope, availability, response arrangements, maintenance costs and the handover if you leave.
07 — Once people rely on it
Agree what happens after launch, and if you leave.
Launching the software, maintaining it and developing new features are different kinds of work. Ask the company to separate them. What is covered during aftercare? What needs an ongoing agreement? How do you report an issue, and when is someone available to respond?
Find out who is responsible for updates, backups, monitoring and recovering from a failure. Avoid assuming that paying for hosting means all of those jobs are covered. Equally, a support agreement should say what is included rather than relying on the phrase “ongoing support”.
Before signing, establish ownership and access for the source code, data, hosting accounts and documentation. Ask what another developer would need to take over. Any third-party products and licences should be identified separately; paying for custom development does not mean you own the software it connects to.
It is reasonable to stay with a team because it knows your business and does good work. You should also understand the practical steps and costs involved if that relationship changes.
08 — Our perspective
Where Launched fits.
Launched is a fit to explore when your project connects several parts of the business: a customer portal linked to existing records, tools for staff, an ordering process, or a connection between your website, CRM and accounting software. We work through what to keep, what to connect and what needs building.
You speak directly with the people doing the work. For projects with several moving parts, we use a shared workspace for the proposal, plan, updates, files and decisions. You can see what is ready, what needs your input and what happens next. Our approach page explains how reviews, handover and support are agreed.
A project behind the advice
A replacement CRM, with the right tools around it.
For a recruitment agency, the existing CRM could not connect to other software. We selected a replacement, tested its API and migrated the records. We then built the website, custom applications and sales dashboards around it, using Airtable for business data and n8n for connections. We continue to work with the agency as its technology and product team.
The project combined an existing product with custom development. That distinction matters: the business needed a working system, and a newly built CRM was not a requirement.
Read the recruitment projectIf an existing product can do the job with a sensible setup, buying it may be the right decision. If you need custom work, use the questions above to compare the team and proposal with the work your business actually needs.