Guide

Build or buy: when existing software is enough and when it is not.

As a software developer we have an obvious interest in building things. This guide is written to be useful anyway: most businesses should buy or configure existing software first. Here is how to tell when that stops being true.

Key takeaways

If a mature product does most of what you need, use it.
Custom work pays off where your process is a real advantage or off-the-shelf tools do not fit.
There is a middle path: configure and connect existing tools, building only the missing piece.
Count the whole cost: subscriptions, workarounds, build, maintenance and switching.
Decide on evidence, with a short trial where possible.

Three routes, not two

Buy and adopt. Use a product as it is and adjust your habits to it. Cheapest to start, quickest to run.
Buy and extend. Use a product for its core, then add automation, integrations or a small custom module around it.
Build. Create software to fit your process exactly. Most flexible and most costly, and you take on maintenance.

Signs that buying is the right call

The job is common: accounting, email, basic bookings, payroll, standard shop checkout.
A product covers about 80% of your needs and the rest is tolerable.
You have no distinctive process to protect.
You need it soon and cannot wait for a build.
You do not want to own maintenance and security upkeep.

Signs that building may pay off

Your process is unusual, and fitting it to a product's way of working would hurt.
You are paying for many licences, or for a tool plus long chains of manual workarounds.
You need several systems to work together, and no tool does it.
The software is part of what customers buy from you: a booking experience, a portal, a proprietary service.
You want to own the data and the relationship rather than rent them.
Volumes or pricing models make per-user subscriptions expensive at your scale.

The costs people forget

Buying: yearly price rises, per-user fees as you grow, paid add-ons, limits on exporting your data, and the effort of configuring and training.
Building: maintenance, hosting, security updates, the time of whoever manages the product, and the risk that the builder is unavailable later.
Either: the cost of switching later. Check how easily you can export your data, and who owns what.

A quick way to decide

Write down the five jobs the software must do. Mark which are routine and which are particular to you.
Try two or three existing products against those jobs, with real examples, using trials.
List what is missing and what it costs you each month, in time or lost sales.
Compare three-year costs of each route, including the forgotten ones above.
Choose the lightest option that covers the gaps, and plan how you would change course if you were wrong.

An illustration: a design studio's project tracking

Imagine a small studio that pays for a project-management subscription but still tracks client approvals in email and a spreadsheet. (An illustrative scenario, not a client.)

Rebuilding the whole tool would be overkill. The sensible route is "buy and extend": keep the product for tasks, and add a small client-approval page connected to it, so approvals are recorded and reminders go out. If, a year later, the studio's process has grown so unusual that the product gets in the way, a full build can be reconsidered with real experience behind it.

Frequently asked questions

Is custom software more expensive?

Up front, usually yes. Over several years it depends on how many users you have, how many workarounds you currently pay for and what the product costs as you grow.

Will you tell us if we should just buy something?

Yes. We would rather scope a small extension than sell you a large build you do not need.

Can we start with a product and replace it later?

Often yes, and it is a sensible way to learn what you really need. Keep your data exportable from the start.

Not sure whether to build?

Describe what you have and what is missing. We will tell you honestly whether it needs custom work.

Request a project quote