Build, Buy Or Integrate? How We Decide For Each Problem
Custom software is not always the answer. A practical framework for deciding whether to build, buy an existing product or integrate the tools you already have.
When a business has a technical problem, the conversation often jumps straight to a solution: "we need an app", "let's buy a CRM", "can we automate this?". Each might be right. But the most expensive mistakes we see come from picking the answer before understanding the question.
There are really only three moves for any part of a system: build it, buy it, or integrate what you already have. Here is how we decide between them.
Start with the problem, not the technology
Before comparing options, write the problem down in one or two sentences that a non-technical person would agree with. For example: "Sales orders take two people half a day to re-enter into accounting, and errors reach customers' invoices."
A clear problem statement makes the options comparable. "We need an ERP" is a solution. "Order data is entered three times and nobody trusts the totals" is a problem, and it might be solved by an ERP, an integration, or a change in process.
When to buy
Buy when the problem is common and the way you solve it is not what makes your business different. Accounting, payroll, email, e-commerce checkouts and help desks are mature categories with products that have absorbed years of edge cases you do not want to rediscover.
Buying is usually the right call when:
- Many businesses have the same need, so good products exist.
- You can adapt your process to the product without losing anything important.
- Total cost of ownership, including licences, setup and training, beats building and maintaining your own.
The risks to check are lock-in (can you get your data out?), fit (how much of your process are you bending?), and whether the product can connect to the rest of your systems.
When to integrate
Integrate when you already have good tools that each do their job, but the work between them is manual. This is the most underrated option. Many businesses do not need new software; they need their existing systems to share data.
Signs that integration is the answer:
- People copy data from one system into another.
- The same customer or product is stored in several places with different details.
- Reports require exporting and merging spreadsheets.
A well-designed integration with proper logging and error handling often removes more manual work than a new system would, at a fraction of the disruption. Our Art in the Middle project is an example: artwork sales, event tickets and customer emails lived in disconnected tools, and the solution was one platform tying the CMS, Stripe payments and automated emails together.
When to build
Build when the thing you need is specific to how your business works and that specificity is valuable. Custom software makes sense when:
- No product fits without crippling compromises.
- The process is a genuine differentiator, something competitors cannot easily copy.
- You need control over the experience, the data or the roadmap.
Building has the highest upfront cost and ongoing responsibility: someone must maintain, secure and improve it. That is worth it for the parts of the business that matter most, and rarely worth it for commodity functions.
Most answers are a mix
In practice, good architectures combine all three. A typical result might be: buy the accounting system, buy the e-commerce platform, build the customer portal that reflects how you actually work, and integrate them so data flows without anyone re-typing it.
The decision is made per component, not once for the whole project.
The questions we ask
For each part of the system, we work through the same short list:
- What exactly is the problem, and how will we know it is solved?
- Is this need common or specific to this business?
- What do the existing systems already do well?
- What will it cost to run and maintain in three years, not just to launch?
- What happens to the data if we change our minds later?
Answering these honestly usually makes the choice obvious, and it produces a design that can be explained to everyone who has to live with it.
If you are weighing these options for your own systems, our solution architecture work starts exactly here. You can also describe the problem to us.
