Buy, configure, integrate or build: how to choose

When current ways of working become hard to manage, a common reaction is: “We need our own system.” Before deciding to build, compare at least three other options: buying an existing product, configuring one, or connecting tools already in use.

There is no fixed ranking of these four approaches. The sensible choice is the one that reliably supports critical business responsibilities at the lowest long-term cost.

Four approaches, different problems

Approach	When it fits	Main trade-off
Buy	Common needs with mature products available	Adapt processes to the product and pay ongoing subscriptions.
Configure	A product largely fits; fields, permissions and rules need adjustment	Deeper changes are limited by the platform.
Integrate	Several useful tools need to exchange data automatically	Interfaces, failed synchronisation and data consistency need maintenance.
Custom development	Critical processes have specific rules existing products cannot reasonably support	Higher upfront investment and ongoing responsibility for the product.

Real solutions often combine approaches: an existing CRM, a custom commission module and an interface to synchronise completed sales.

Is this process a genuine business differentiator?

Payroll, basic accounting, email and file storage are similar across many businesses. Mature products are often safer and cheaper. Personal preferences alone may not justify rebuilding them.

By contrast, custom development may be worthwhile when a process directly determines customer service, revenue allocation or delivery control, and a general-purpose product would force the team to abandon important rules.

Ask:

• Do competitors do this work in almost the same way?
• Would adopting the software’s default process damage customer experience or operational control?
• Do these specific rules genuinely improve revenue, efficiency or risk control?
• Is the business willing to maintain them over time?

“We have always done it this way” is not a distinctive advantage. “This rule determines commission ownership, and errors directly affect the team’s income” might be.

Compare total cost of ownership, not just the first quote

Total cost of ownership (TCO) includes costs that continue after acquiring a tool.

For an existing product, consider:

• Per-user, monthly or transaction fees.
• Data imports, training and process changes.
• Additional modules you must purchase.
• Whether you can export complete data when changing products later.

For custom development, consider:

• Requirements clarification, design, development and testing.
• Launch, data migration and staff training.
• Security fixes, maintenance and changes to external services.
• Updates when business rules change.
• People responsible for deciding the product’s direction.

Comparing only “subscription fees” with “development fees” can lead to the wrong conclusion.

Use a decision table to reduce subjectivity

Score each candidate from 1 to 5 on these dimensions:

Dimension	Question
Critical process fit	Does it support non-negotiable business rules?
Speed to launch	How soon can staff actually use it?
Three-year cost	What is the total cost of acquisition, implementation, maintenance and change?
Data control	Can you access, export and trace your own data?
Integration	Can it connect reliably with existing tools?
Maintenance burden	Who handles problems and rule changes?

Weights need not be equal. For sensitive data, permissions and auditability may matter more than speed. For testing a new business, speed may be more important.

When to pause custom development

Do not rush to build when:

• The team cannot explain the current process.
• Different owners give different answers about the same rule.
• A reasonably priced product already covers the main needs.
• Nobody in the business can own priorities and acceptance.
• Requirements come from isolated incidents rather than recurring problems.
• Expected benefits rest on vague ideas such as “more professional” or “we may need it later.”

Pausing does not mean abandoning the idea. Use existing tools for a while and let real operations reveal which limitations are worth solving.

Reserve custom work for what is worth owning

A business need not choose between “buy everything” and “build everything.” A more resilient approach is to leave standard problems to mature products and control the processes that are genuinely distinctive and important.

That reduces development costs and focuses limited attention where it can improve the business most.

---

This article compares common ways of acquiring technology. No single approach is best for every business.