Build vs buy software comes down to one question dressed up as a hundred: is your workflow standard enough that a vendor already solved it, or specific enough that conforming to their assumptions costs you more than owning the code? Off-the-shelf wins on time-to-value and predictable year-one cost. Custom wins on fit, integration depth, and total cost once per-seat fees compound past year two. Most teams get the decision wrong because they price the license, not the five years.
We build custom software, AI agents, and ERP systems for a living — which means we get the call from both directions: teams who bought and outgrew it, and teams who built when they should have bought. This is the framework we actually use, with the numbers, not a vendor's checklist designed to end in "book a demo."
The quick answer
| Your situation | Lean |
|---|---|
| Workflow is ≥80% standard, need it working this quarter | Buy |
| Team under ~25 people, per-seat pricing still cheap at your size | Buy |
| Validating whether a process is even worth automating | Buy first, build later if it sticks |
| Workflow has real custom shape — vendors force constant workarounds | Build |
| You need integration depth no vendor's API roadmap covers | Build |
| The system is competitive infrastructure, not a cost center | Build |
| Team is 50+ and per-seat fees are compounding past build cost | Build |
If none of those clearly fit, you're in the genuine gray zone — see the scorecard below.
What "build vs buy" actually means
Build vs buy is the decision between building custom software around your exact workflow and buying (or subscribing to) an existing product and configuring it to approximate that workflow. It's a specific case of the older make-or-buy decision operations teams have made for decades — and like the classic version, it's not really an engineering question, it's a total-cost-of-ownership question wearing engineering clothes. Gartner's TCO framework exists precisely because the sticker price of "buy" and the quoted estimate of "build" both undersell what the decision actually costs over time.
Buying gets you working software fast, a vendor's roadmap, and support you don't have to staff. Building gets you software shaped exactly to how you already win, no per-seat tax, and no risk of a vendor's pricing change or acquisition rewriting your cost structure overnight. Neither is the "grown-up" choice. Each is correct for a different shape of problem.
The question that actually decides it: cost of ownership, not cost of purchase
Every build-vs-buy framework online tells you to "consider your budget." That's not useful — it compares a quoted number (build) against a monthly number that feels smaller because it's spread out (buy). The comparison that matters is the same unit: total cost over a fixed horizon, usually 3 to 5 years.
Buy's real cost is: setup + (per-seat price × seats × months) + the cost of every workaround you build around the tool's limits + the migration cost when you eventually outgrow it. Build's real cost is: the build itself + hosting + a maintenance retainer or in-house time — and that's it, because there's no seat multiplier and no forced migration.
The break-even point for most mid-market custom builds against a comparable SaaS subscription lands around 18 to 30 months. Below that horizon, buy usually wins outright. Past it, the math starts favoring build — especially once your team or usage is still growing, because SaaS costs scale with you and a custom build's cost mostly doesn't.
When buying is the right call
- Your use case is genuinely commodity. Standard CRM, standard support ticketing, standard project tracking — a mature product already solved this better than a first build will.
- You need it live this quarter, not this year. Time-to-value is the one dimension where buy reliably wins.
- Your team is small enough that per-seat economics are still cheap. Ten seats at $50/month isn't the fight worth having.
- You're validating whether the workflow is even worth automating before you commit engineering time to it.
- Compliance certifications (SOC 2, HIPAA) are table stakes and a vendor already carries them — inheriting that beats building your own compliance program from zero.
When building is the right call
- Your workflow is specific enough that every off-the-shelf tool forces a workaround — and the workarounds are piling up into their own maintenance burden.
- You need integration depth a vendor's pre-built connectors don't reach: a legacy system, a proprietary format, an internal API.
- The system is strategic — it's part of how you compete, not a back-office utility. You don't want your competitive workflow living on a vendor's roadmap.
- Your team has passed the size where per-seat pricing stopped being a rounding error and started being a budget line that grows every quarter regardless of whether usage grows with it.
- Data ownership or a no-retention requirement is non-negotiable and no vendor's data-processing terms actually satisfy it.
The cost math, by system type
Here's what most build-vs-buy content skips: the math is completely different depending on what you're deciding to build. A generic "build vs buy" framework that treats an internal dashboard, an AI agent, and an ERP system the same way is giving you the wrong answer for at least two of the three. These are the ranges we actually quote, by category:
| System type | Typical build cost | Typical "buy" cost (3-yr) | Where the math tips |
|---|---|---|---|
| Internal tool / web app | $15k–$40k fixed scope | $10k–$50k+ (seats × growth) | Tips to build fast if the workflow is non-standard; a focused build ships in 4–6 weeks |
| AI agent | $10k–$200k | $0–5k setup + per-seat/usage | Tips to build once volume or workflow specificity passes what a configured platform handles |
| ERP system | $50k–$750k | $250k–$600k+ (5-yr, mid-market) | Tips to build when customization on a packaged ERP would otherwise exceed a couple of workflow tweaks |
These aren't invented ranges — they're the bands we've quoted clients across custom software builds, AI agent projects, and custom ERP, including the full 5-year ERP cost comparison we publish for that specific decision. The pattern holds across all three: the smaller and more standard the system, the more buy tends to win; the bigger and more workflow-specific it is, the more the license-forever math starts losing to owning the code.
The hybrid path most frameworks don't mention
You don't have to pick once and live with it. The strongest pattern we see — and the one we recommend most often — is: buy first to validate that the workflow is worth solving at all, then build once you know exactly what "solved" looks like for you. The bought tool becomes free discovery. It shows you which 20% of your workflow the vendor's assumptions don't cover, and that 20% becomes the actual spec for the custom build, instead of guessing upfront.
We've run this exact pattern with clients moving from a configured AI agent platform into a custom-built agent once the edge cases were clear. It works the same way for internal tools and ERP: pilot on something off-the-shelf, keep a running list of every workaround, and use that list as your build requirements the moment the list gets longer than the shortcuts save you.
A build-vs-buy scorecard you can actually run
Score your decision on four dimensions. The dominant signal — not a weighted average — usually picks the path:
- Workflow standardness. What share of your process matches what the vendor's marketing page describes? Under 80% match means you'll be fighting the tool constantly.
- Data and integration depth. Does the system need to reach into infrastructure a vendor's API doesn't cover, or handle data the vendor's terms won't let you keep in-house?
- Volume and team size. Is per-seat or per-usage pricing still a rounding error, or has it become a line item that grows whether or not your value from the tool grows with it?
- Strategic ownership. Is this system part of how you win, or a back-office cost center? Competitive infrastructure belongs to you; utilities can belong to a vendor.
If three of four point the same direction, that's your answer. If they're split, you're in the genuine gray zone — that's usually a 20-minute conversation, not a six-month evaluation.
Common questions
Buying is almost always cheaper in year one. Building is often cheaper over 3 to 5 years, once per-seat costs compound and the workarounds you'd otherwise build around a vendor's limits stop being free. The honest comparison uses the same time horizon for both — usually 3 to 5 years — not a one-time quote against a monthly price.
For most mid-market builds compared to a comparable SaaS subscription, the break-even lands around 18 to 30 months. Below that horizon, buy usually wins on pure cost. The horizon shortens the faster your team or usage is growing, since SaaS cost scales with you and a custom build's cost mostly doesn't.
Almost always buy, with one exception: if the system you're deciding on is your product or your core competitive edge, building is right even at startup size — that's not a back-office decision, it's the business. For every supporting system (CRM, support, internal ops), buy until the workarounds cost more than the license.
CRM and support ticketing are almost always buy. Internal ops tools for a non-standard workflow, AI agents handling volume or edge cases a platform doesn't cover, and ERP for a business whose operations don't match a packaged system's assumptions are the recurring "build" cases we see across client work.
Yes, and it's often the smartest path. Use the bought tool to validate the workflow and surface exactly where it doesn't fit. That gap becomes your build spec. We've helped clients run this pattern moving from a configured platform into custom software, a custom AI agent, or a custom ERP once the edge cases were clear.
The framework is the same — workflow fit, integration depth, volume, strategic ownership — but the cost bands are not. An internal tool tips toward build around $15k–$40k; an AI agent's math depends heavily on usage volume; ERP's packaged "buy" cost compounds hardest of the three because per-seat and module fees scale with headcount for years. Price your specific system type, not a generic average.
If you're mid-decision and want the real number for your specific case instead of another framework, the fastest path is a fixed-scope quote — we'll tell you honestly if buy is the better call, even though we only get paid on build.