How do you choose a software development company? Judge evidence over claims, insist on a written scope before a price, confirm the code will be yours to keep, and check how they run things after launch, not just how they pitch. Then weigh whether you could work with these people for months and whether the company is sized to your problem rather than much larger. The biggest name and the cheapest quote are rarely the right answer. The one that fits your problem, and can prove it, usually is.
The reason this is hard is that the surface signals are easy to fake and the ones that matter are not. A polished site, a wall of client logos, and a confident pitch tell you a company can sell. They tell you almost nothing about whether it can build the thing you need and stand behind it. The criteria below are the ones that survive contact with a real project.
What should you actually evaluate?
In rough order of importance, these are the things worth weighing before anything else.
- Evidence over claims: ask to see how they have solved a problem like yours, with specifics about what they actually did, not a wall of logos. A company that can walk you through a real piece of work, its constraints, its decisions, and its outcome, is showing you how it thinks.
- The right depth of skill: a real software build needs design, engineering, performance, security, and the parts users never see, all done well. Confirm the range is genuinely covered, not just that the headcount is large.
- A written scope before a price: a number with no written scope is a guess dressed as a quote. The scope of what is included, what is not, and when, is the thing that actually protects you, fixed price or otherwise.
- Ownership of the result: the code, the data, and the accounts should be yours to keep, built on standard tooling with no lock-in. This is the single criterion that keeps every other supplier decision open later.
- How they run it in production: ask what happens after launch, who monitors it, who fixes it, and who answers when something breaks late on a weeknight. A company that only prices the build and goes quiet on running it is handing you the hard half.
- Communication you can live with: you will work with these people for months, so clear, regular, plain-language updates matter nearly as much as technical skill. Most projects fail in the gaps between people, not in the code.
- Proportionate to your size: the largest firm is not the safest choice, and is often the most expensive way to be one client among hundreds. The right company is sized so your project actually matters to it.
A polished site and a wall of logos tell you a company can sell. They tell you almost nothing about whether it can build your thing and stand behind it.
What questions should you ask before you sign?
Good questions do more than gather information. They reveal how a company thinks, and the evasive answers are as telling as the clear ones. Ask each of these directly, and listen for whether the answer is specific or vague.
- Ask for evidence of a similar problem solved, and what specifically they did versus what the client did.
- Ask who owns the code, the data, and the accounts at the end, and ask for it in writing.
- Ask what the software will cost to run after launch, not just to build.
- Ask how they handle a fixed price against a written scope, and what changes it.
- Ask who you will actually work with day to day, and what happens when that person is unavailable.
- Ask how they test, and how they move a release live without breaking what is already running.
What are the red flags?
Some signals should make you slow down or walk away. None is automatically disqualifying on its own, but more than one or two together is a pattern.
- A price with no written scope behind it.
- A portfolio that is all logos and no story of what was actually built.
- Reluctance to put ownership of the code and data in writing.
- Hourly-only billing that quietly transfers the risk of an overrun onto you.
- A "we can build anything" pitch that asks nothing about your business first.
- Lock-in by design: their platform, their hosting, their keys, so leaving means rebuilding.
Most of the criteria above have a mirror image: a healthy signal to look for, and the red flag that sits opposite it.
| Criterion | What to look for | The red flag |
|---|---|---|
| Track record | A real piece of work walked through: its constraints, decisions, and outcome | A portfolio of logos with no story of what was built |
| Scope and price | A written scope of what is included, what is not, and when, before a number | A price with no written scope behind it |
| Ownership | Code, data, and accounts yours to keep, on standard tooling, in writing | Ownership retained and licensed back to you, or lock-in by design |
| Billing | A model that holds the overrun risk where it belongs | Hourly-only billing that quietly transfers overrun risk to you |
| Fit | Questions about your business before any pitch | A 'we can build anything' pitch that asks nothing first |
| After launch | A clear answer on who monitors, fixes, and answers when it breaks | A quote for the build that goes quiet on running it |
Who owns the code and the IP?
This is the question that costs the most when it is left unasked, and the answer should be simple: you own it, and the contract says so before work starts. You paid for it, it encodes how your business works, and owning it is what lets you extend it, move it, or hand it to someone else later.
The arrangement to watch for is ownership retained by the developer and licensed back to you. It can sound reasonable in the room and it quietly traps you, because the moment you want to change suppliers or bring the work in-house, you cannot. Get ownership of the code, the data, and the accounts written down, on standard tooling you can actually access, and treat any hesitation on this point as a material answer rather than a detail to sort out later. This is one of the decisions that separates a web and product build you can keep from one you only rent.
Do you need bespoke software or an off-the-shelf product?
Often the most valuable thing a good company tells you is not to build. Buy off-the-shelf when a product already does the job well and your needs are common, because rebuilding what you could license is rarely worth it. Reach for bespoke software development services when the process is genuinely your edge, when no product fits without bending your business around it, or when the tools you would otherwise stitch together cost more in workarounds and lost time than a fitted build would.
A company that asks where the line falls for you, and is willing to point you toward buying when buying is right, is judging your problem rather than selling its hours. That instinct, more than any single credential, is what you are actually choosing when you choose well. Pair it with evidence, a written scope, and code you own, and you have most of what separates a build that lasts from one you will be replacing in a year.
