Buying software assets vs commissioning development

Start with the job your customers need done

Write a short acceptance journey before evaluating either route. For stock counting, that might mean importing a product list, counting on an agreed phone, recovering an interrupted connection, reviewing a discrepancy and exporting a result. Include the awkward cases: duplicate imports, missing barcodes, different permissions and corrections. A polished first screen says little about those behaviours.

Mark each requirement as essential at handover, optional later or outside scope. Then ask the seller or developer to explain what exists, what needs configuration and what requires new work. This gives you a comparable brief.

See the starting point you would actually receive

Ask for a demonstration tied to a named source version and an explanation of its environment. A recording, sample-data walkthrough and buyer-environment acceptance test serve different purposes. Watch your critical journey, then ask a technical reviewer to reproduce it from the proposed handover materials. Record any account, service or data dependencies.

For an asset such as CountBuddy, investigate the counting and review workflow. For RAMSNow, examine drafting, editing and PDF output, alongside the responsibility for competent document review. Neither an attractive demo nor existing source establishes that every buyer requirement is already complete.

Separate code from everything that makes it useful

Request a schedule covering source, database structure, tests, documentation, brand assets and deployment instructions. Identify the owner of each item and any third-party conditions. Domains, customer contracts, hosted accounts and credentials are separate questions; they should not arrive by assumption.

For commissioned development, ask the same questions about ownership, permitted reuse, dependencies and access to working source. Possessing a repository is not the same as having all the rights needed for your intended use. Your advisers should review the actual proposed rights, rather than rely on a product label.

Compare the complete route to launch

Put both options into a simple cost-and-responsibility sheet: initial consideration, remaining implementation, migration, security review, provider setup, hosting, maintenance and your own team’s time. List assumptions beside the numbers. A low acquisition price can leave substantial adaptation work; a new-build quote can omit operating and maintenance costs.

Ask who will own the product after handover and whether your team can maintain the chosen stack. Prefer a focused pilot of the essential journey over a long feature wish list. Do not treat an unsupported revenue projection or claimed development saving as money already earned.

Make acceptance and handover observable

Agree the environment, devices, sample data and success criteria before implementation begins. Include a buyer-led rehearsal, clear defect handling, named documentation and a fixed support allowance. Distinguish finishing agreed functionality from answering questions after acceptance. Link payment milestones to deliverables that both parties can check.

If personal data is proposed for transfer, deal with that separately during diligence; do not request live customer records simply to make a demo realistic. The ICO identifies data sharing as part of acquisition diligence when data moves to another controller.

Further reading: ICO: acquisition and data-sharing diligence

Choose the route that fits your operating capability

Buying can suit a team whose essential workflow closely matches the asset and who can complete a bounded handover. Commissioning can suit a materially different process or a need to choose architecture from the outset. A licence with a defined adaptation may offer another route. Bring your customer journey, delivery constraints and questions to the first conversation; they are more useful than asking whether a product is “finished” without defining the destination.