AT A GLANCE
The build-versus-buy decision boils down to six factors: the degree of uniqueness of your workflow and the seriousness of a poor fit, the speed of change, the degree to which you need to own roadmap and data, the heaviness of the integration burden, and the degree of low-level maintenance. Score each in each category from one to five according to your needs. A high degree of uniqueness, seriousness of a poor fit, and concern for owning roadmap and data point to building; a low degree of uniqueness, heavy integration burden, and concerns about maintenance point to buying. In this article you get the model to score yourself.
Most build-versus-buy advice argues for one side. This framework takes a different approach: it provides a structured way to evaluate whether a specific workflow should be built, bought, or handled through a combination of both. We use these factors when working with clients to assess the trade-offs around workflow uniqueness, cost, flexibility, ownership, integration, and long-term maintenance. It complements our guide on when not to build custom software, which focuses on the situations where building is better avoided altogether.
Most build-vs-buy advice argues a side. A framework lets your situation decide.
On this page
The six factors to score
Rate each factor from 1 (low) to 5 (high) for the specific workflow you’re deciding about — not your business in general, but the one process in question. Build-versus-buy is a per-workflow decision, not a company-wide one.
- Workflow uniqueness (high = build)
How different is your process from the standard way this is done? If you work essentially like everyone else, off-the-shelf fits. If the workflow is genuinely distinctive especially if it’s part of how you compete a generic tool will force you to compromise the very thing that makes you different.
- Cost of mismatch (high = build)
What does it actually cost you when the tool doesn’t quite fit? For some workflows, a small mismatch is a minor annoyance. For others, it means daily workarounds, manual steps, and errors that compound. The higher that ongoing cost, the more a tailored fit is worth paying for.
- Rate of change (high = lean buy, or build for flexibility)
How often does this process change? A stable, well-understood workflow is a good candidate to encode in custom software. A process still changing every month is risky to build around — you’d be hard-coding something that won’t hold still. If it’s changing fast, either wait until it stabilizes or buy something flexible in the meantime.
- Ownership needs (high = build)
How much do you need to own the data, the roadmap, and the system itself? If vendor dependency — their pricing, their priorities, their ability to deprecate features or get acquired — is a real strategic risk for this workflow, ownership tilts toward building. If it’s a commodity you’d happily let someone else run, it doesn’t.
- Integration burden (high = caution either way)
How many other systems does this need to connect to? Heavy integration is a cost on both sides — a custom build has to build those connections, and an off-the-shelf tool has to be wired in and kept in sync as it changes. A high score here doesn’t point cleanly to build or buy; it points to “whichever you choose, budget seriously for integration.”
- Maintenance capacity (low = lean buy)
Can you sustain the long-term ownership that custom software requires? Custom software you own is custom software you maintain — it needs care over time. If you have no capacity or partner for that, buying (where the vendor maintains it) is the more honest choice, even if a custom build would fit better in theory.
How to read the score
There’s no magic threshold, but the pattern is clear once you’ve scored the six:
Pattern | What it points to |
|---|---|
High uniqueness + high cost-of-mismatch + high ownership | Build — this workflow is worth owning |
Low uniqueness + low cost-of-mismatch + low ownership | Buy — it’s a commodity; don’t build it |
High maintenance concern, everything else moderate | Buy, or build only with a maintenance partner in place |
High rate of change | Wait for the process to stabilize, or buy flexibly for now |
High integration burden | Either path works — but budget heavily for integration |
Mixed / middling scores across the board | Hybrid — buy the commodity parts, build the distinctive part |
The real point isn’t to produce a perfect number. It’s to make the tradeoffs visible — and force the conversation — before you spend money in either direction. A score that comes out genuinely ambiguous is still useful: it tells you the decision deserves more thought than a default “just buy it” or “let’s build it.”
A worked example
Take a staffing agency deciding how to run its core placement workflow, the client-to-mandate-to-submission-to-placement pipeline that is the actual business. Score it: workflow uniqueness is high (4–5 — a generic applicant tracking system, built for in-house hiring, doesn’t even have the concept of a client); cost of mismatch is high (4–5 — a poor fit means candidates lost, clients unanswered, revenue a guess); ownership matters (the candidate data and client relationships are the asset); rate of change is low (the agency model is stable). Integration burden is moderate, maintenance manageable with the right partner. That profile points clearly toward building.
Now score the same agency’s payroll and accounting: uniqueness low, cost of mismatch low, ownership not strategic, mature products everywhere. That points just as clearly toward buying. Same company, two workflows, two opposite answers — which is the whole point of scoring per workflow rather than per company.
The answer is often hybrid
Running the model honestly, most companies don’t land on pure build or pure buy. They land on hybrid: buy the commodity pieces — identity, billing, email, accounting — where a mature product clearly wins, and build custom only on the one or two workflows that genuinely set them apart and score high on uniqueness and cost-of-mismatch. Hybrid is usually the honest answer whenever only part of the workflow is strategic. That combination keeps you fast and cheap on the parts that don’t differentiate you, and in control of the parts that do. The framework’s real value is often showing you which parts are which.
Build the part that makes you different. Buy the parts that don’t.
One thing the score can’t capture
The model structures the decision; it doesn’t make it for you. Judgment still matters — especially in reading whether a workflow is truly distinctive or just feels that way, and whether a process is stable enough to encode. That’s where an honest outside read helps, and it’s the conversation worth having before committing real money in either direction. The worst outcome isn’t choosing build or buy; it’s choosing either one without having actually weighed the factors that should have decided it.
Frequently asked questions(FAQs)
Score six factors for the specific workflow: uniqueness, cost of mismatch, rate of change, ownership needs, integration burden, and maintenance capacity. High uniqueness, high cost-of-mismatch, and high ownership point toward building; low uniqueness with high maintenance concern points toward buying. It’s a per-workflow decision, not a company-wide one.
No. For commodity workflows a mature product already handles well — payroll, accounting, email — buying is usually the smarter, cheaper choice. Custom earns its place only where the workflow is genuinely distinctive and a poor fit would cost you real money over time.
Mixed scores usually point to hybrid — buy the commodity pieces and build only the workflow that genuinely sets you apart. That’s where most companies land when they run the model honestly, and it’s often the healthiest answer.
This is the scoring model for the decision itself. The companion question , when not to build - is the case for restraint and the signs you shouldn’t build at all. Use this framework to weigh a specific workflow; read the other when you suspect the answer is “don’t build.”
Weighing a build-versus-buy decision?
Bring your workflow to Logic Square. We’ll apply this framework to your specific business process and help you evaluate what should be built, what should be bought, and where a hybrid approach makes more sense. The goal isn’t to recommend custom software by default — it’s to help you make the right technology decision based on workflow fit, cost, integration, ownership, and long-term value. Veteran-led, building production software since 2012.
Work with us
