Insights · 5 min read

Build vs buy software: the question that decides it

Build vs buy is rarely about price. It is about whether the software is a commodity or your competitive edge, plus the costs nobody budgets for.

By GGP Editorial

Every company hits the same decision eventually: build this ourselves or buy something off the shelf. Most of the time the honest answer is not the one people want to hear. Build is expensive, buy is constraining, and the right choice comes down to one question: is this software part of what makes your business different?

We build custom software for a living, and we still tell clients to buy off the shelf when that is the better call. A partner who always says "build" is selling hours, not advice. Here is how we actually think about it.

Start with the question that matters

Is the process you are automating a commodity or a differentiator?

If it is a commodity — payroll, generic accounting, a standard CRM — buy. You are not going to out-payroll a vendor who has spent ten years on it, and your team has better things to do than maintain a payroll module.

If it is the thing your customers pay you for — the trading engine, the booking flow, the pricing model — build. Buying a white-label version of your core product means your competitor can buy the same one tomorrow.

SignalLean buildLean buy
The workflow is your competitive edgeYes
Off-the-shelf tools cover 80% of itYes
You need to change it oftenYes
It has to integrate with many internal systemsYes
Compliance and rules change slowlyYes
You have a small team and a short deadlineYes

The table is a starting point, not a formula. The real test is whether the software shapes the business or just supports it.

The costs people forget

Build cost is not the quote you get at the start. It is the quote plus years of maintenance, hosting, upgrades, and the time your team spends explaining the system to new hires. Buy cost is the licence fee plus the cost of bending your process to fit the vendor's assumptions, which shows up as manual work and spreadsheets.

A custom financial or property system we build is something we maintain for years, and we plan for that from the first sprint. That is a different conversation from a one-off project that gets handed over and abandoned.

A concrete example

Take two projects we have seen up close.

A property manager needed to collect rent, track leases, and reconcile payments. Off-the-shelf property tools exist, but none handled their specific lease types and payment flow, so they built a system that matched their business instead of forcing the business to match the software. That was a build.

A separate client wanted standard accounting for a small team. We told them to buy an accounting tool and spend the saved budget on the part of their product that actually earns revenue. That was a buy.

Same company, same year, two different answers. The question was not "what does it cost" but "what does this software need to be for us to win".

Where the middle path lives

It is rarely a clean either-or. The common middle paths are:

  • Buy a platform and build the part that makes you different on top of it.
  • Buy for the commodity areas and build only the core, connecting them with a small integration layer.
  • Build a version one that is deliberately thin, then decide whether to keep going or replace it.

We see this a lot with point-of-sale and payments. A restaurant does not need to build a card terminal integration from scratch; it needs a POS that fits its menu and workflow. Buy the boring parts, build the ordering flow and the kitchen display, and you get the best of both.

What we tell clients before any build

Before we quote anything, we ask whether the problem is already solved by a tool that costs a fraction of the build. If it is, we say so. It costs us a sale sometimes, and it is still the right answer. Trust shows up in the projects we do take on: the ones where the software is the product, or close enough that buying would put the business in a box.

We have built across fintech, IoT, property, and payments for clients in Brazil, South Africa, Singapore, and the US. The industries change, the question does not: will this software make the business different, or just keep the lights on?

A good vendor will also talk about the exit path: who owns the code, can you take it elsewhere, and what happens if the relationship ends. Buy means the vendor owns the roadmap; build means you own the code and the decisions that come with it.

If you are on the fence, write down what the business looks like in three years if you buy versus if you build. The option that gives you room to move is usually the right one.

Talk to us about your project

Need help applying this?

Tell us what you are building and where you are today. We typically reply within 24 hours.