Most custom software projects do not fail on the code. They fail on the contract, the handover, and one question nobody asked in the first meeting: who owns this once it is built? Before you compare portfolios, put these seven checks to any firm you are considering. They apply whether you are a ministry, an enterprise or a growing organisation commissioning bespoke systems.
The Seven Checks
Ownership, problem understanding, written scope, handover, security, exit terms, and a willingness to recommend not building. A firm that cannot answer all seven in writing is not ready to hold your systems.
1. Who owns the code, the data and the accounts?
The repository, the hosting and the data should sit in accounts your organisation controls from day one. If everything runs on the firm's own platform, you are not buying software. You are renting it, and the licence never ends.
2. Do they understand the problem before proposing the solution?
A good firm asks how the work runs today, who runs it and what breaks. If the first meeting is a demo of their favourite stack, they are selling a product, not solving your problem.
3. Is the scope written down, including what is out of scope?
Insist on deliverables, timeline, acceptance criteria and exclusions in writing, ideally for a fixed fee. Open-ended hourly work makes the cost impossible to forecast and the finish line impossible to see. A written scope is also the first thing a systems review produces.
4. What does handover look like?
Ask to see a handover document from a previous project. It should be written for your team, not for the developer who built it: how the system works, how to run it, who to call. Software nobody on your side understands is a dependency, not an asset.
5. How are security and data handling treated?
Ask where data lives, who can access it and how credentials are managed. For public institutions and regulated organisations, raise this in the first conversation. Retrofitting it later costs far more than planning it. Role-based access and row-level security shows what good looks like at the data layer.
6. What happens if you part ways?
Another team should be able to take over without rebuilding. Look for standard technologies, documented code and no licence fee just to keep the system running. A clear exit clause is the sign of a firm confident in its work.
7. Will they tell you when not to build?
Sometimes the right answer is to connect the tools you already own. A firm that never recommends integration over a build has a conflict of interest. I explore this in CRM Build vs CRM Integration and When Not to Automate.
Ask early, ask in writing
None of this requires a technical background. It requires asking the questions early and putting the answers in the contract. After 17+ years advising governments, enterprises and agencies across EMEA, the pattern is consistent: the projects that go well are the ones where ownership, scope and handover were settled before the first line of code. If you would like an independent review of a proposal before you sign, that is part of the work behind Automation & Software Intelligence, which is built so your organisation owns every system it receives. For wider programmes, Systems Governance & Advisory covers oversight of the vendors involved.
Frequently Asked Questions
Related reading: CRM Build vs CRM Integration, When Not to Automate and Lead Capture Automation.
Reviewing a software proposal?
An independent systems review checks ownership, scope and handover before you sign.
Request a Systems Review →
