How to decide whether to build, buy or connect software

Buy software when the problem is common and the available product fits the way your team can work. Connect existing tools when the workflow matters but the individual capabilities are already good enough. Build custom software when the workflow creates a meaningful advantage, carries constraints generic products cannot support or needs to become a product in its own right.

The decision is not a contest between cheap and expensive, or fast and ambitious. Each route creates a different operating commitment. The useful question is which commitment gives the business the clearest path to the outcome it needs.

Define the outcome before comparing software

Start with the change the business needs, not a preferred tool or technology.

“We need a CRM” names a category. “Our team needs one reliable view of every qualified lead, its owner and the next promised action” names an operating outcome. The second statement makes several options comparable. A standard CRM may solve it. Existing tools may only need a clean connection. A custom system may be justified if the qualification and handover model is genuinely particular to the business.

Write down five things before reviewing options:

• The person responsible for the outcome.
• The work they are trying to complete.
• The point at which the current approach fails.
• The information, decision or handover that must improve.
• The evidence that would show the new approach is useful.

This keeps a product demonstration from becoming the definition of the problem. It also prevents custom development from beginning around an idea that a well-configured existing tool could already handle.

Buy when the capability is common

Buying is usually the strongest route when the required capability is mature, widely shared and not where the business needs to be distinctive.

Email delivery, accounting, video meetings, file storage and routine customer records are examples of capabilities for which established products may already carry the difficult infrastructure, security and maintenance work. The business benefits from adopting that capability without owning its full technical life.

Buying still requires product judgment. A feature checklist can hide poor operating fit. Test the actual workflow:

• Can the people responsible complete the ordinary task without a workaround?
• Do permissions match who may see, change and approve information?
• Can important data enter and leave in a usable form?
• Are failure, support and recovery paths clear?
• Does the pricing remain sensible at the expected team size and usage?

A purchased tool is not automatically cheaper if the team must reshape its work around it, duplicate records elsewhere or pay for a much larger package to access one necessary control. The right product is the one whose constraints the business can accept deliberately.

Connect when the parts work but the handoffs do not

Connection is useful when the business already has capable tools, but people carry information between them manually.

A form may collect a request correctly, a CRM may hold the customer record and a project system may manage delivery. The weak point is the handoff: copying information, assigning an owner, confirming receipt or keeping status consistent.

In that case, replacing every tool or building a new platform may create more change than value. A focused integration or workflow layer can make the existing system behave like one operation.

Map the connection explicitly:

• Which event starts the workflow?
• What information moves, and which system remains its source of truth?
• What rule determines the next action?
• Who handles missing, duplicated or conflicting information?
• What should a person see when the connection fails?

The last question matters. A connection is not complete because two APIs exchanged data once. It needs an owner, a visible state and a recovery path. Otherwise the manual work has not disappeared; it has become harder to see.

Build when the workflow is part of the advantage

Custom software earns its place when the business needs control over a workflow that materially shapes its customer promise, operating capacity or commercial model.

That may be a client experience that no standard product can express clearly, an internal decision system built around particular rules and responsibilities, or a venture whose software is the product customers will use. It may also be a workflow with unusual permissions, data boundaries or failure states that generic products handle poorly.

Custom does not mean every component must be invented. A working digital product can use reliable services for authentication, payments, communication or storage while reserving custom design and engineering for the experience that makes the product valuable.

Before building, test the case:

• What must the business be able to control that available products do not allow?
• Which part of the workflow creates meaningful differentiation?
• Who will own the product after the first release?
• What data, support and maintenance will the operation require?
• What is the smallest complete version that can prove the decision was sound?

If the answer is only “we want everything in one place”, the business may need a clearer operating model before it needs custom software.

Compare the full operating cost

The visible purchase price or development quote is only one part of the decision.

For a bought product, include configuration, licences, training, data migration, premium features, process changes and the cost of leaving later. For connected tools, include monitoring, integration limits, failed runs, duplicated permissions and the person responsible for recovery. For custom software, include discovery, design, engineering, hosting, security, support, product ownership and continued improvement.

Also account for the cost of poor fit. A cheaper system can become expensive when it creates repeated administration, delays a critical handover or prevents the business from changing an important rule. A custom product can become equally expensive when it reproduces standard capabilities and leaves the team responsible for software that does not strengthen its offer.

Compare each route over the period in which the decision must remain useful. The goal is not to predict every future expense precisely. It is to expose which responsibilities the business is choosing to carry.

Prefer the most reversible credible step

When the evidence is incomplete, choose the smallest step that can answer the important question without closing off the next route.

That might mean trialling a bought product with one real workflow, connecting two systems before replacing either, or building a narrow custom surface on top of services the business can change later. Define the review point in advance: what must improve, what the team will observe and what decision follows.

Reversibility is not the same as avoiding commitment. The step still needs to be complete enough for people to use honestly. It should simply avoid a large migration, long contract or broad custom build before the operating fit is understood.

A practical build, buy or connect record

Capture the decision on one page:

• Outcome: the business or customer change required.
• Owner: the person accountable for the workflow and its result.
• Distinctive work: what must be particular to this business.
• Standard capability: what an established product can reasonably provide.
• Handoffs: where information, responsibility or status moves between systems.
• Constraints: permissions, data, integrations, support and failure conditions.
• Lifecycle commitment: the cost and ownership each route creates.
• Reversible test: the smallest credible step and the evidence it must produce.
• Decision: buy, connect or build, with the reason the other routes were rejected.

The record is short by design. Its purpose is to make the trade-off reviewable, not to create certainty through a long requirements document.

Build only what deserves to be owned

A strong software decision gives the business more capability without creating ownership it cannot support. Sometimes that means adopting a proven product. Sometimes it means making existing tools work as one system. Sometimes the ambitious vision genuinely needs a new digital product.

Dial8 helps founders and teams make that distinction through strategy, design, engineering and commercial validation. We build things that widen possibility by putting custom effort where it creates a useful new choice—and using simpler, established capabilities where they already do the job well.