How to buy custom software without getting burned

Most bad software purchases go wrong before any code is written. The buyer did not know what they were buying, the seller did not say what they would deliver, and both found out at the end. This guide is the checklist we wish every client had before their first call with us, or with anyone else.

Start with the problem, not the product

Write one page in plain words. What slows your team down today? Who does the work, and where does the information live now? What would be different a year after the software goes live? You do not need technical terms. A developer who cannot work from this page is the wrong developer.

Decide whether you need custom software at all

If a ready-made tool does most of what you need, buy it. Custom software pays off when your process is genuinely different, when several tools no longer talk to each other, or when subscription fees keep growing. A good supplier will tell you when the honest answer is to buy off the shelf.

Ask for a quote that prices each part

A single number hides the trade-offs. A quote that lists every screen and feature with its own price lets you remove what you do not need, and shows you what the expensive parts are. It also makes it clear what a change will cost later, because the change is added to the same list.

Read the contract for these five things

• Who owns the code. It should be you, once the project is paid for. Read our guide on source code ownership.
• What is delivered and when. Named milestones with working software at each one.
• What happens after launch. Support hours, response times and the monthly cost.
• Third-party costs. Hosting, AI usage, payment gateways and paid components, listed separately.
• How to leave. Handover of code, documents and accounts, whatever the reason.

Check progress against working software

Ask to see the design before any code is written, then ask to see working parts at regular check-ins. A supplier who only shows slides until the end is asking you to trust rather than check. You should be able to click through your own software long before launch.

Plan for the first year, not the launch day

Software needs updates, backups and someone to call. Agree that before you start, so launch is the start of a working relationship rather than the end of one.

Where to go next

The other guides in this series cover what moves the price, how long projects take, how to pay and how to choose a company; the published ones are listed below. When you are ready, tell us what you need and a senior engineer will reply within one working day.