The buy vs build software question usually gets framed as a choice between two options. In practice there are more, and “build” is often not the best one. Sometimes the right answer is to keep what you have, connect it better or remove something that no longer helps.
The Technology Decision Model is how BOSYX frames those choices. It lists eight interventions so that each option gets considered on its merits, rather than defaulting to whatever was proposed first.
What is a technology decision framework?
A technology decision framework is a consistent way to compare options before committing money and time. Ours has eight options:
| Option | What it means | Usually the right call when |
|---|---|---|
| Keep | Preserve a tool or process that works. | It does its job, people use it well and replacing it would add cost without clear gain. |
| Buy | Adopt a proven product. | The process is common in your field and a mature product handles it without major workarounds. |
| Extend | Improve or configure an existing tool. | The current tool is mostly right but missing fields, workflows, reports or settings it can support. |
| Integrate | Connect systems so data moves between them. | Staff re-enter the same information in several places, or systems disagree about the same record. |
| Automate | Remove repetitive manual steps. | A step is frequent, rule-based and stable, and the process around it is already clear. |
| Modernize | Update a system that holds the business back. | A core system is outdated, hard to change, poorly supported or creating security or data risk. |
| Build | Create what is genuinely missing. | No existing product supports a critical or differentiating workflow, and the business can own the result. |
| Retire | Remove what no longer helps. | A tool duplicates another, has few users or adds cost and complexity without clear value. |
Why do keep and retire belong in a build or buy software decision?
Two of the eight options involve adding nothing, and that’s deliberate. Keeping a working tool avoids the cost and disruption of change. It also respects the knowledge the team has built up around it. Replacing something that works because it looks dated is one of the more common ways organizations spend money without improving operations.
Retiring is the option most often skipped. Businesses tend to accumulate tools: a trial that became permanent, a product one team adopted, a system kept “just in case” after a migration. Each carries licensing, security exposure and another place data can drift out of sync. Removing what no longer earns its place simplifies the system and frees budget for changes that matter.
How do you decide between buy vs build software—and the other options?
The model works best once you understand how the business actually operates. If the workflow, ownership and information flow aren’t clear yet, it’s hard to judge whether a tool is failing or simply being asked to cover for a process gap.
With that picture in hand, a few questions help narrow the options:
- Is the problem the tool, or how it’s used? If the tool can do the job with configuration or training, extend it before replacing it.
- Is data being re-entered? That usually points to integration rather than a new system.
- Is the step repetitive and rule-based? It may be a candidate for automation, but only after the process has been simplified and standardized.
- Is the workflow standard in your field? Buying is usually faster and cheaper than building.
- Is the workflow unique and important to how you compete? That’s where building starts to make sense.
- Is a core system limiting growth or creating risk? Modernization may be needed, often in stages rather than all at once.
Cost, timing, internal skills and the team’s capacity for change all shape the answer. The right decision depends on the operating context.
The BOSYX view: The right technology decision is the smallest change that solves the real problem and that the business can sustain. Sometimes that’s building something new. Often it’s keeping, connecting or removing what’s already there.
Integrate vs replace: which comes first?
When two systems don’t talk to each other, replacing both with one new platform can look tidy. It’s also the most disruptive option. If each system does its own job well, integrating them so data moves automatically often solves the real problem—duplicate entry and conflicting records—at a fraction of the change.
Replacement becomes the better answer when a system is unsupported, can’t be integrated reliably, or forces workarounds even in its core function. If it isn’t clear which situation you’re in, a structured technology assessment can settle it before money is committed.
Why do most plans combine several options?
Real situations rarely call for a single move. Consider a service business that schedules work in a spreadsheet, invoices from an accounting package and tracks clients in a CRM. A sensible plan might look like this:
- Keep the accounting package, which works well and that the finance team knows.
- Retire a second CRM one team adopted separately, after merging its records.
- Buy a proven scheduling product to replace the spreadsheet.
- Integrate scheduling, CRM and accounting so a completed job creates an invoice without re-keying.
- Automate reminders and status updates to clients once the workflow is stable.
- Build only a small client-facing view if no product offers the specific access clients need.
This is an illustrative example, not a formula. The point is that the plan draws on several options, in a sequence where each step makes the next one easier. Order often decides whether a plan succeeds: retiring duplicates early reduces the number of connections to build later, automating before a process is stable tends to encode today’s workarounds, and building before requirements are clear turns development into expensive discovery.
Common questions
Is it cheaper to buy or build software?
Buying is usually cheaper and faster for standard processes. Building can make sense when a workflow is unique and important, but the comparison should include years of maintenance, not just the initial cost.
When should we integrate systems instead of replacing them?
When each system does its own job well and the main problem is duplicate data entry or records that don’t match. Replace when a system is unsupported, risky or failing at its core function.
Can one project use several of these options?
Yes, and most do. A typical roadmap keeps what works, retires duplicates, and combines buying, integrating and automating, with building reserved for what is genuinely missing.
The principle
Treat “build” as one option among eight, not the default. Understand how the business works, consider every intervention on its merits and combine them in an order the organization can absorb. The goal is a system that works, not the most technology.
Weighing whether to build, buy or connect what you already have? Explore Business Systems consulting.