In short
- Insist on something usable in months, not at the end
- Ask who can read the code besides the person who wrote it
- Data migration is routinely the largest hidden cost
- Settle ownership of code, data and hosting before work starts
Choosing a software development company is the highest-stakes vendor decision a small business makes, because the thing being built will end up holding your operations. If it is wrong you do not simply rebuild it; you migrate off it, which is a different and far worse problem.
These are the checks that matter, roughly in the order the risk arrives.
Start with the problem, not the software
A good firm will spend the first conversation trying to understand a process rather than describing a solution. If somebody proposes an architecture before they understand how your orders actually move, they are selling what they already know how to build.
Come prepared to describe one process end to end, including the parts that are messy and handled by somebody remembering. The messy parts are where software projects fail, and a serious supplier will go looking for them.
Insist on something usable early
Clutch's data puts the average custom software project at around thirteen months. Thirteen months of building before anything is in real use is thirteen months of accumulating risk on an assumption nobody has tested.
Ask what the smallest genuinely useful version looks like and when it would be in production. Not a demo, not a staging link — someone in your business using it for real work. If that answer is more than a few months away, ask why, and keep asking.
The figures behind this are in software development cost in India.
Who can read the code besides the person who wrote it?
This is the question that separates a supplier from a dependency. Ask how the code is documented, whether another developer could pick it up, and what their handover looks like when somebody leaves their team.
The honest version of this risk: a single developer who understands your system entirely, working at a firm with no documentation habit, is a business continuity problem that will not appear on any invoice until the day it does.
Discovery is not an upsell
A paid discovery phase — a few weeks of working out exactly what is needed, ending in a specification you own — looks like a way to charge you before building anything. It is usually the cheapest part of the project.
What makes it worth paying for is that the output is portable. If the discovery produces a document you own, you can take it to another supplier. If it produces nothing you can read, you have paid for a sales process.
Data migration is usually the project
Everyone budgets for the build. Almost nobody budgets properly for moving fifteen years of records out of spreadsheets, an old system, and three people's inboxes into something structured.
Ask specifically: who cleans the data, who decides what happens to records that do not fit, and how migration is tested before cutover. If the answer is vague, that vagueness will reappear later as a delay. We wrote about the usual trigger for all this in signs your business has outgrown spreadsheets.
What a weak answer sounds like
| You ask | A weak answer | What you want instead |
|---|---|---|
| How long will this take? | A confident number, before any discovery | A range, with the assumptions that would change it |
| Who owns the code? | “Don't worry, you do” | A contract clause, and a repository you can access |
| What if requirements change? | “We're flexible” | A named change process, and how it is priced |
| How do you test? | “We test as we build” | Who tests, what is automated, and who signs off |
| What about security? | “It's all encrypted” | Specifics about access control, backups and recovery |
The handover that protects you
Agree these before work starts
- You own the code, the data and the specification outright
- The repository is in an account your company controls
- Hosting and database accounts are in your name
- Documentation sufficient for another developer to continue
- A tested backup and a tested restore — not just a backup
- What support costs in year two, in writing
Build, buy, or wait?
The best software development company will sometimes tell you not to build. Off-the-shelf software that fits eighty per cent of your process is usually a better purchase than custom software that fits all of it, because you are also buying everyone else's bug reports and a product roadmap you do not have to fund.
Custom earns its cost when the process is genuinely your advantage, or when no product fits without distorting how you work. That judgement is the subject of custom software versus off the shelf.
Our own approach is on the software development page.