There's a version of this question that's basically unanswerable: "Should we build custom or buy off-the-shelf?" Asked in the abstract, it depends on so many variables — stage, budget, competitive position, team skills, time pressure — that any answer is either a hedge or wrong.
The version that's actually answerable is more specific: "Should we build this particular workflow, in our particular business, at our particular stage?" That's a question with a reasonably clean framework behind it. We use a version of it with almost every client that asks us "can you just build us a custom tool?" The honest answer is often no — or not yet, or not this part of it.
This post walks through the framework we use, the signals that push a decision one way or the other, and a few real scenarios where the "obvious" answer was wrong.
Start by splitting your business into layers
Before you make any build-vs-buy call, you need to separate the layers of your business. Most companies have at least three:
Commodity layer. The stuff every business does the same way: email, payroll, accounting basics, calendars, video calls, expense reports. Buy this. Building your own payroll system is a great way to spend six figures not serving your customers.
Differentiated layer. The stuff you do similarly to others in your industry but with meaningful variations. Your sales process, your customer onboarding, your support workflows. You'll usually start off-the-shelf here, then customize or replace pieces as your version gets specific enough to matter.
Competitive edge layer. The stuff that is your business — the thing customers pay you for. A logistics company's routing engine. A marketplace's matching algorithm. A fintech's risk model. An agency's pricing engine. If an off-the-shelf tool can do this, you don't actually have a moat.
The mistake we see most often is treating all three layers the same. Companies that build custom payroll software are usually the same companies that use a generic CRM for their competitive edge. Both decisions are backwards.
The five signals that push toward custom
Once you're looking at a specific workflow, these are the signals we watch for:
1. Repeated workarounds
If your team has built three or more workarounds around a tool — spreadsheets that live alongside it, double-entry workflows, macro scripts, manual reconciliation — that's a signal the tool no longer matches your business. Every workaround is hidden labor cost that compounds quietly.
2. Per-seat pricing at scale
A tool at $40/user/month is fine for 10 people. It's a real line item at 400 people. If your current or projected seat count makes a SaaS tool more expensive than an amortized build cost, the math changes.
Rough rule of thumb: if annual SaaS spend on a single tool exceeds ~$150–250K and growing, a custom build often pays back within 18–30 months. This is especially true for internal tools where your usage patterns are predictable and your customization needs are stable.
3. Competitive advantage depends on the thing
If the workflow is how you beat competitors, using the same software they use gives away your edge. Your pricing model, your underwriting logic, your matching engine — these usually deserve custom. Commodity functions don't.
4. Integration overhead is becoming a second team
If you have 3+ engineers spending significant time gluing SaaS tools together, you've accidentally built a bespoke system — you're just doing it with duct tape. At some point, replacing the underlying tools with a purpose-built system is less work than maintaining the integrations.
5. Vendor risk on a critical function
SaaS vendors get acquired, sunset products, change pricing, or shift direction. For a function that would genuinely hurt your business to lose or migrate, vendor risk is a real cost. Custom software means you own the risk directly instead of depending on someone else's roadmap.
The five signals that push toward off-the-shelf
Going the other direction:
1. The workflow is standardized across your industry
If 95%+ of companies do this workflow the same way you do, a mature SaaS tool already encodes that workflow. You'd spend six months reinventing it.
2. You're still validating
In early-stage product development, you usually don't know what you actually need. Building custom before you've validated the workflow means rebuilding everything once you learn what's really required. Ship off-the-shelf, learn, then decide.
3. Strong API ecosystem reduces integration tax
Some SaaS tools (Stripe, Twilio, Sendgrid) have such good APIs that integration is nearly frictionless. When the glue is cheap, the cost structure of SaaS is much better.
4. You need it running this week
Custom software on a realistic timeline is weeks to months at minimum. If your constraint is "we need this live in seven days," off-the-shelf is your only option.
5. You don't have the team to maintain it
Custom software is an ongoing liability, not a one-time cost. Someone has to maintain it, fix its bugs, adapt it as the business changes. If you don't have engineering capacity and don't want to pay for ongoing partnership, off-the-shelf's vendor-maintained model is a feature, not a bug.
Three scenarios where the obvious answer was wrong
Scenario 1: The B2B SaaS that built its own CRM
A 30-person SaaS company we worked with was paying for a mid-market CRM that wasn't quite fitting their workflow. They asked us to build a custom replacement. After talking it through, we pushed back: their sales process wasn't actually different enough from the industry norm to justify a custom build. What they needed was better configuration of the existing tool and better integration with their product usage data. The right build was a thin integration layer and a Retool dashboard, not a full CRM. Total cost: a fraction of the custom build, shipped in weeks.
Scenario 2: The e-commerce company that stayed on Shopify too long
A client running a niche vertical marketplace had built more and more logic on top of Shopify — custom apps, external pricing engines, inventory systems glued in with Zapier. Each piece made sense individually. In aggregate, they were spending more on glue than they would have on a purpose-built system, and the customer experience was degrading as the seams showed. Here, the custom build was the right call. Off-the-shelf had already lost, but the stepwise migration had hidden it.
Scenario 3: The internal tool that didn't need to exist
A services company asked us to quote a custom CRM, custom project management tool, and custom time tracking. We ended up recommending off-the-shelf for all three — because their workflows weren't differentiated from industry norms, and their engineering team didn't have maintenance capacity. Instead, we built a lightweight reporting layer that pulled data from all three SaaS tools into a single dashboard. It addressed the real pain point (visibility across tools) without the 12-month custom build.
The practical decision framework
When a client asks us "build or buy?", we walk through these questions:
- Which layer is this — commodity, differentiated, or competitive edge?
- How many workarounds have you built around the current tool?
- What's your 5-year total cost of ownership at projected growth, for both options?
- How different is your version of this workflow from the industry norm, honestly?
- Do you have the team to maintain custom software over 3+ years?
- What's your tolerance for vendor risk on this specific function?
If the workflow is commodity, standardized, and not a competitive edge — buy. If it's a competitive edge, you have the team to maintain it, and the 5-year numbers work — build. If it's somewhere in between, start with SaaS, instrument it well, and be ready to migrate when the signals start pointing the other way.
There's no single right answer. There's a right answer for each workflow at each stage. Getting those calls right, systematically, is one of the most underrated skills in running a growing software business.
If you want to talk through a specific build-vs-buy decision, our team does this kind of evaluation regularly — see our software development services or reach out and we'll dig into your specifics.