Choosing a software partner: what to settle before you commission
For: Buyers without an internal IT function
Updated: 2026-09
Choosing a software partner is decided less by references than by four contractual points: who owns the result, who holds access to the systems, what a handover looks like, and what happens when the engagement ends.
Supplier selection for software is usually run on references and price. Neither says much about how things look two years later, when the project is live, the team has changed and a modification is needed.
This list concentrates on the points that count at exactly that moment. It is written for buyers without an internal IT function, who cannot assess the work itself on technical merit.
The checklist
- 01
Check references for comparability
Not whether references exist but whether they match your undertaking: similar size, similar domain, similar operational demands. A reference from a different order of magnitude says little.
Done when: At least one reference is comparable in size and domain, and you have spoken to that buyer.
- 02
Settle rights in the work contractually
Who owns source code, design and documentation once paid for. The question sounds obvious and regularly is not settled in contracts.
Done when: The contract expressly transfers rights in the work product, and any third-party components used are named.
- 03
Secure access to accounts and infrastructure
Domain, hosting, repository and third-party services should sit on your accounts with the supplier as an authorised user. The reverse effectively blocks any change of supplier.
Done when: All production accounts are in your company’s name and you hold independent access.
- 04
Match the contract model to how well defined the work is
Fixed price demands a clear specification and penalises change. Time and materials demands steering capability on your side. Both work; the wrong model for the situation does not.
Done when: The chosen model matches how well defined the work is, and the handling of change is regulated.
- 05
Require handover readiness from the start
Documentation, reproducible deployment and no undocumented bespoke constructions. The measure is whether a different supplier could take the project over.
Done when: It is contractually agreed what documentation is to be delivered and in what state.
- 06
Address dependence on individuals
Establish who will actually do the work and what happens if they leave. With small suppliers the dependence on individuals is real and should be stated openly.
Done when: The people doing the work are named and a procedure for a change of personnel is agreed.
- 07
Regulate the exit in advance
What happens on termination: handover of source code, transfer of accounts, a period of supported transition. After a falling-out none of this is negotiable any more.
Done when: The contract describes the services owed on termination, including a handover period.
- 08
Settle operations after completion
Who runs, monitors and updates the system once the project ends, and on what terms. A project with no settled operating arrangement becomes a problem by the second year at the latest.
Done when: An agreement on maintenance, response times and updates exists.
Common mistakes
- —The domain or hosting sits with the supplier, making any change of supplier dependent on their cooperation.
- —A fixed price is agreed for work whose scope is still unclear. Both sides lose — the buyer flexibility, the supplier margin.
- —Operations after completion go unregulated. Updates lapse, and an unexpected remediation lands two years later.
- —References are read but never called. A conversation with a previous buyer regularly yields more than the entire tender pack.
What this checklist does not cover
- —This list concerns selection and contract, not technical assessment of the work itself. That needs expertise on your side or independent oversight.
- —Contractual wording belongs with lawyers. The points here name what to discuss, not how to phrase it.
- —Public sector buyers are bound by procurement law, which largely prescribes the process and is not reflected here.
- —Price comparison is deliberately out of scope, because bids on differing scopes are not a sound basis for comparison.
Parent service: Custom Software Engineering
Matching offers
IT strategy & roadmap
An IT strategy answers which technical investments advance your business goals most — and in what order. The result is a prioritised roadmap that turns a diffuse wish list into an executable plan with clear action areas and milestones.
Next.js web application at a fixed price
A bespoke web application on Next.js — fast, strong on SEO and maintainable, with a clearly bounded feature set and a binding fixed price. The result is a production-ready application without the usual cost surprises of open-ended hourly billing.
FAQ
How do you spot an unsuitable partner without technical knowledge?
By the kind of questions they ask. A supplier who asks about usage, operations and edge cases before quoting has done comparable work. One who quotes immediately usually has not.
Is a large supplier the safer choice?
Not necessarily. Larger firms offer more resilience to staff changes, smaller ones often more attention. What decides is whether your project is meaningfully large for that partner.
Should you obtain several bids?
Yes, but only on an identical basis. Bids against differently understood requirements are not comparable and lead to a decision on the wrong criterion.
More checklists
EU AI Act conformity: a checklist for the first pass
A workable first pass through the EU AI Act has six parts: know which AI runs in the business, determine your role for each system, classify under Article 6, check transparency duties separately, ensure AI literacy, and file everything so it can be found under scrutiny.
High risk or not: reasoning an Annex III classification properly
High-risk classification follows a fixed order: first the deployment area under Annex III, then whether the system plays a substantive role in the decision, then the exemption in Article 6(3). Each of those steps has to be documented with reasoning.
AI literacy under Article 4: from intention to evidence that holds
Article 4 asks for a sufficient level of AI literacy, measured against role, context and the people affected. It becomes workable in four moves: form roles, set a depth per role, train accordingly, and record attendance with date, content and the link to the role.