Home InsightsSoftware Development

Software Development

How to Choose a Software Development Company: A Buyer's Checklist

Choose a software development company on evidence you can check, not presentation: a system of theirs in daily use that you can click around, the engineers who would write your code, an itemised quote with its assumptions stated, and a written list of what you receive if you leave. Compare two proposals written against the same brief.

Prabhu SolutionsPublished 8 October 2026Last reviewed 8 October 202612 min read

On this page

How do you choose a software development company?
Should you build bespoke software or buy a product?
What kinds of software supplier are there?
What should a software company show you before you sign?
How do you compare two software proposals?
What questions should you ask bespoke software developers?
Who should own the source code and the data?
How do payment terms and fixed prices change the risk?
Does it matter where a software development company is based?
When is hiring a software development company the wrong choice?
What do you need to bring to a software project?

How do you choose a software development company?

Choose a software development company on evidence you can check, not on presentation: a system of theirs in daily use that you can click around, the engineers who would write your code, an itemised quote with its assumptions stated, and a written list of what you receive if you leave. Compare at least two proposals written against the same brief.

The names — company, agency, studio, consultancy — tell you little. Ask three things instead. Are the people who sell the work the people who write it? Does the supplier make its money from building custom systems or from selling a product? And will anyone still be able to explain a decision made a year ago?

Start before you shortlist anyone, with whether you need to build at all. Bespoke software development is the right answer for some businesses and the wrong one for many, and what bespoke software costs will tell you what you would be committing to before you speak to a single supplier.

The point
Start before you shortlist anyone, with whether you need to build at all.

Should you build bespoke software or buy a product?

Buy a product when your process is broadly standard and a mature product already does it well. Build when your process is distinctive, when every product nearly fits but forces awkward workarounds, or when per-seat licences grow faster than the value you get. An honest software company will tell you to buy when buying is right.

The clearest signal that fit is wrong is a team that has quietly gone back to a spreadsheet alongside the product you bought. Custom CRM against off-the-shelf works through that decision for one common system, and the reasoning carries to others. If the system in question is a CRM, CRM development is where the build side of that choice sits.

There is also a middle path: keep the product for the standard functions and build only the distinctive part, joined by an integration. A supplier who only ever recommends one end of this range, whichever end it is, is selling rather than advising.

The point
A supplier who only ever recommends one end of this range, whichever end it is, is selling rather than advising.

What kinds of software supplier are there?

Software suppliers fall into six groups: product vendors, implementation consultancies, bespoke development companies, freelancers, in-house teams and outsourced project teams. The labels blur, so ask what the supplier earns from: licences, configuration or custom builds. That decides what it is most likely to recommend, whatever your problem is.

Supplier	What they earn from	Fits when	Watch for
Product vendor	Licences, usually per user.	Your process is standard and the product covers it.	Paying for features you do not use, and changes limited to what the vendor allows.
Implementation consultancy	Configuring and integrating someone else's platform.	You have already chosen a platform and need it set up.	Advice that always leads back to the same platform.
Bespoke development company	Building and supporting custom systems.	Your process is distinctive, or several systems must be joined together.	Unclear ownership and proposals that are not itemised.
Freelance developer	Day or project work.	A small, well-defined build with one accountable person. Freelancer, agency or in-house sets out the trade-offs.	No cover for illness or holiday, and skills outside their speciality.
In-house team	Salaries.	Software is the permanent core of the business and changes constantly.	Recruitment effort, single points of failure and a role that must justify itself between projects.
Outsourced project team	Delivering a defined project remotely. Software outsourcing covers how it works.	A bounded system to build and then run.	Working-hour overlap and the quality of the handover.

What should a software company show you before you sign?

It should show a system in daily use that you can click around, name the engineers who would write your code, and explain how your work would be tested on realistic data before it goes live. A case study document describes working software; it is not evidence of it. Ask for the real thing, or an introduction to its owner.

A live system in daily use, walked through by the supplier or by the client who owns it. Click around, and ask what the client asked to change after launch.
The engineers, by name. Who would write your code, and are they the people who presented the proposal?
A staging environment from a current project, holding realistic data, and an explanation of how testing is split between them and you.
Documentation from a past project: what a handover pack looks like, including deployment notes and a description of the data model.
How security is handled: roles and permissions, encryption, backups, and a restore that someone has actually performed rather than only scheduled.
The outputs of a discovery stage: a process map, a scope with its exclusions, a prototype. If a supplier has never produced these, discovery has not happened.
A reference you can speak to. Ask what went wrong and how it was handled. A project where nothing ever went wrong is a project nobody remembers properly.

How do you compare two software proposals?

Compare proposals element by element against the same written brief: scope, assumptions, integrations, data, testing, ownership, support and payment. A proposal you cannot compare line by line is a proposal you cannot challenge. Ask each supplier to itemise, and be wary of one number covering everything.

Element	A clear proposal	A vague proposal
Scope	Phases, with what is in phase one and an explicit exclusions list.	A list of features with no boundaries.
Assumptions	States what it assumes about your users, your data and your other systems.	Assumes everything will work and does not say so.
Integrations	Names each system to be connected and what is known about its interface.	“Integrations included” with no detail.
Data	Says what will be migrated, cleaned and reconciled, and who checks it.	Leaves migration out or treats it as a formality.
Testing	A staging environment, realistic data and a stage where you test it yourself.	Testing described as ongoing or as your responsibility after launch.
Ownership	You own the source code, schema, designs and data on final payment.	Silent, or a licence to use the system.
Support	Separates fixing defects, updating dependencies and building new features.	One line saying support is available.
Payment	Tied to working software you have seen running.	Tied to dates, or large sums before anything is demonstrated.

What questions should you ask bespoke software developers?

Twelve questions work on any bespoke software developer, ours included. A good supplier answers each plainly and puts the answer in writing. The ones to worry about change the subject, quote a price instead of an answer, or say it is covered in the contract. Ask them before the commercial discussion starts.

“Can you show me a system you built that is in daily use?” A good answer is a screen share or an introduction to the client, not a brochure.
“Where will I test this before it goes live?” A good answer names a staging environment with a copy of your real data. Testing in production is a warning.
“Who owns the source code and the data, and what happens the day I stop paying?” A good answer is that you own both on final payment, with the repository transferred.
“Who writes the code, and will I meet them?” A good answer names people and what they do. Subcontracting is common, but it belongs in the conversation before the first invoice.
“How will I see progress?” A good answer is something you can log into at a regular interval, not a status email. Problems stay hidden when you can only see a report.
“How is it secured, and when did someone last restore a backup?” A good answer covers access control, encryption and an actual restore.
“What does support cover once it is live, and what does it cost?” A good answer separates defects, updates and new work, and says which you are buying.
“Can the quote be itemised?” A good answer breaks the work into recognisable parts you can question or drop. The drivers behind a quote are explained in the cost of bespoke software.
“What are you assuming about my data and my other systems?” A good answer lists assumptions and says how each will be tested during discovery.
“How are changes to scope handled?” A good answer is a written change note with a cost and an effect on the plan, agreed before the work is done.
“What happens if the person who built it leaves your company?” A good answer shows documentation, a second engineer who knows the code and standard technologies another developer could pick up. Systems built as web applications on common technologies are easier for another developer to pick up.
“What would you tell me not to build?” A good answer is specific and costs the supplier some work. If everything you propose is a great idea, you are talking to a sales process.

Who should own the source code and the data?

You should, on final payment: the source code, the database schema, the designs and the data, with the repository transferred to an account in your name. A licence back to your own system is a different product sold under the same word. Ask every supplier the question and ask for the answer in the proposal.

A proper handover is a list, not a reassurance. The repository with its history, the schema, the designs, the credentials, the hosting accounts, the build and deployment instructions, and written documentation. Ask for that list at proposal stage and check it against what you receive. Patterns to watch for: a release fee to obtain your own code, an in-house framework that only the supplier can maintain, and hosting accounts you never see.

Standard, widely used technologies matter because they decide whether another developer can pick the work up. A system built on a framework nobody else uses is owned in name only. Ask which technologies are used, whether any are proprietary and who else could maintain them.

The point
Standard, widely used technologies matter because they decide whether another developer can pick the work up.

How do payment terms and fixed prices change the risk?

A fixed price is only meaningful once the scope is written and the unknowns are known, so it belongs after discovery, not before. Tie payments to working software you have used, not to dates or hours, and never pay in full for work you have not seen running on your own data.

Time and materials is honest when the requirement is genuinely unclear, but it needs review points or a cap so the spend stays visible. A fixed price on a vague brief tends to produce either a padded figure or a dispute later. Neither model is safe on its own; the structure around it is what protects you.

Product builds are a special case, because the scope moves by design. If you are building something to sell rather than a system to run your own business, SaaS development raises its own questions: how the first release is defined and what is cut to reach it. What a SaaS MVP costs explains the drivers.

The point
If you are building something to sell rather than a system to run your own business, SaaS development raises its own questions: how the first release is defined and what is cut to reach it.

Does it matter where a software development company is based?

Less than most buyers assume, and more than some suppliers admit. Development runs through video calls, a staging environment and shared documents, so a postcode rarely decides the result. Working-hour overlap, who you can reach and whether anyone answers for the work after launch matter more. Ask where the engineers are and which hours they keep.

Prabhu Solutions is registered in Oldbury, in the West Midlands, and works with businesses across the UK. Our delivery record to date is international rather than UK-based, and we would rather say so here than let you find out later. Who we are is set out plainly, and if you want to talk it through, contact us.

The same questions apply whoever you ask. Which hours do the engineers work? How much of your working day overlaps with them? Who attends the review calls? What does the contract say about response times? The outsourcing guide goes through the risks that come with a team working remotely.

The point
The outsourcing guide goes through the risks that come with a team working remotely.

When is hiring a software development company the wrong choice?

Hiring one is the wrong choice when a mature product already fits your process, when the requirement is still changing weekly, when your budget is too thin for the scope you describe, or when nobody on your side can own decisions. Fix that first, or choose a different route.

An unsettled requirement is cheaper to learn with a product or a spreadsheet, because building software around a process that keeps changing is expensive learning. A thin budget points to a smaller first phase or to buying. A project with no owner stalls on decisions however good the supplier is. And if what you need is extra engineers inside a team you already run, that is a hiring or contractor decision rather than a project; the trade-offs between a freelancer, an agency and a hire apply.

If software is the permanent core of your business and needs continuous change by people who know it deeply, build the team in-house. If the thing you need is a phone app, how to choose an app development company is the better guide, and if it is mostly a website, how to choose a web development company is. A bounded system you build once and then run is the usual case for outsourcing software development.

The point
If software is the permanent core of your business and needs continuous change by people who know it deeply, build the team in-house.

What do you need to bring to a software project?

Bring a named decision-maker, access to the people who will use the system, a description of the problem in their words, and your existing data in whatever state it is in. Software projects stall on decisions and data far more often than on technology, and a good supplier will ask for all four early.

You do not need a specification. Writing one is part of what a supplier should do, and a spreadsheet plus a clear frustration is a workable starting point. What you do need is someone with the authority to say yes or no quickly, because how long a project takes depends on how fast decisions are made on your side, how many processes and integrations are in phase one, and how clean the data turns out to be.

Expect the early questions to be uncomfortable. A supplier who asks about the exceptions, the awkward customer and the spreadsheet only one person understands is taking your process seriously. One who accepts the first description without question is likely to build the documented process rather than the real one.

The point
A supplier who asks about the exceptions, the awkward customer and the spreadsheet only one person understands is taking your process seriously.

Questions people ask about this

How do I choose a software development company?

Ask to click around a system they built that is in daily use, ask who writes the code and whether you will meet them, and ask what you receive in writing if you leave. Compare two itemised proposals against the same brief. Plain, written answers matter more than a polished portfolio.

What questions should I ask bespoke software developers?

Ask who owns the source code and data, where you will test before launch, who writes the code, how progress is shown, what support covers and what leaving looks like. The twelve questions above work on any supplier. If you ask only three, ask about ownership, testing and exit.

Should I buy software or have it built?

Buy when your process is standard and a mature product covers it. Build when your process is distinctive, products only nearly fit, or per-seat licences are growing. A middle path keeps the product and builds only the distinctive part. Buying or building a CRM shows the reasoning.

Who owns the code when a company builds bespoke software for me?

It should be you, on final payment, together with the schema, designs and data, with the repository transferred to your account. Some suppliers licence the system back to you instead. Neither is automatically wrong, but you should know which you are signing, so ask in writing before you agree anything.

Is a fixed price or time and materials better for software?

Neither is better on its own. A fixed price works once discovery has produced a written scope. Time and materials suits a genuinely unclear requirement, with review points so spend stays visible. Whichever you choose, tie payments to working software you have seen running on your own data.

Does a software development company need to be UK-based?

Not necessarily. The work runs through video calls, a staging environment and shared documents. What matters more is working-hour overlap, who you can reach and who answers for the system after launch. Ask where the engineers are, which hours they keep and what the contract says about response times.

What should a software development proposal include?

It should include phased scope with exclusions, stated assumptions, named integrations, a data migration plan, a testing approach on a staging environment, ownership terms, a description of support and payments tied to working software. A proposal with one total and no breakdown cannot be compared with anyone else's.

What are the warning signs when choosing a software developer?

Watch for a single unexplained price, no staging environment, engineers who are never named, reluctance to discuss leaving, and agreement with every idea you propose. None proves a bad supplier. Each is a reason to ask a follow-up question and to wait for a written answer.