Software
Custom vs off-the-shelf software isn't one decision - it's a decision per workflow. We break down the framework we use with clients, with real examples.
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.
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.
Once you're looking at a specific workflow, these are the signals we watch for:
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.
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.
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.
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.
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.
Going the other direction:
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.
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.
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.
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.
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.
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.
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.
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.
When a client asks us "build or buy?", we walk through these questions:
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.
The commodity/differentiated/competitive-edge framework applies across industries, but how it maps to specific workflows varies. Here's how we typically apply it in four sectors we work in regularly.
Generic scheduling tools work fine for most small practices - until they don't. The breaking point usually involves EHR integration: when appointment data, billing codes, and patient records live in separate systems that don't talk to each other, the workaround cost becomes significant and the compliance exposure grows. HIPAA requirements also constrain which off-the-shelf tools are acceptable, and many SMB-focused tools have vague BAA policies or charge extra for compliant tiers. For patient-facing workflows that touch PHI, a purpose-built integration layer between your scheduling tool and your EHR often makes more sense than hoping the two vendors eventually ship a native connector. Custom wins here more often than the initial sticker price suggests.
Document management, client intake, and matter tracking are relatively standardized across law firms and professional services - mature tools exist and most firms don't have workflows different enough to justify a custom build. Where things get interesting is billing: the gap between how hours are actually tracked, reviewed, and adjusted and what generic billing software assumes is often large enough to generate meaningful workaround costs. Firms with non-standard billing models (fixed-fee matters, hybrid arrangements, complex client hierarchies) tend to find generic billing software actively fighting their workflow. That's the piece worth evaluating for a custom or heavily-configured alternative.
Shopify plus plugins handles the vast majority of standard DTC e-commerce. The inflection point is when your business model requires logic that doesn't fit Shopify's data model: complex pricing rules, marketplace dynamics, multi-location inventory with custom allocation logic, or loyalty programs that need to integrate with an external data source. When companies start building elaborate Shopify apps to work around these constraints, they've usually already passed the point where a purpose-built system would have been cleaner. The diagnostic question: if you removed all your custom Shopify apps and described what they do, would that description sound like a software product? If yes, you've probably built one accidentally.
There's an irony that comes up often: SaaS companies that sell software to other businesses frequently make poor software buying decisions for their own operations. The instinct is "we build software, so we should buy everything we can." But SaaS companies often have non-standard internal workflows - custom usage-based billing logic, complex entitlement models, intricate trial-to-paid conversion flows - that generic tools handle badly. The result is engineering time spent building workarounds around tools that were supposed to save engineering time. The specific area to audit: anything that touches your own product's data. When your internal tools need to understand your product's data model to work, off-the-shelf tools will always require significant custom glue.
The build-vs-buy comparison almost always focuses on the build cost. The question that gets ignored until it becomes urgent is: who maintains this after it ships?
Custom software is not a one-time cost. It's an ongoing commitment. The software needs bug fixes. The business changes, and the software has to change with it. APIs it depends on get updated or deprecated. The team that built it eventually moves on, and the next team needs to understand what they inherited.
There are two reasonable answers to the maintenance question, and both are legitimate. The first is internal engineering capacity: you have engineers who will own the system, and it's within their scope. The second is an ongoing partnership with an external team - the same team that built it, or a new one brought in with good documentation. What's not a reasonable plan is "we'll figure it out when something breaks."
A rough rule that holds up reasonably well: budget 15-25% of the build cost per year for active maintenance. A $60,000 internal tool should have $9,000-$15,000/year earmarked for upkeep - not as a one-time retainer, but as ongoing capacity. For systems that sit at the competitive-edge layer, that number might be higher because the business is actively wanting to develop new capabilities, not just keep the lights on. For a stable internal tool that rarely changes, it might be lower.
Documentation at handoff is the most underrated item in this entire conversation. Teams that receive a custom system without clear documentation of its data model, its integrations, its deployment process, and its known edge cases spend months re-discovering things the original team already knew. Good documentation isn't a nice-to-have - it's what determines whether the system is maintainable or a liability. Before signing off on a build, confirm that documentation is a deliverable, not an afterthought.
If you're evaluating a custom build and don't have clear answers to "who maintains this" and "what does maintenance cost," you're not ready to make the build decision yet. Our software development team structures engagements to include documentation and post-launch support from the start - specifically because we've watched what happens when those aren't agreed on upfront.
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.
Go deeper
Hiring the cheapest bidder for software is rarely cheap. Teams that skip user research deliver products users ignore - then charge again to rebuild them. This post breaks down the measurable business case for user-focused development and how to spot agencies that actually do it.
Competing on features against entrenched software is a losing game. The products that break through do it by owning a workflow, integrating deeply into existing tools, or delivering UX that makes alternatives feel clunky. This guide covers all three strategies and when to use each.
The same failure patterns appear in software project post-mortems again and again. They are not caused by bad engineers - they are caused by avoidable process gaps. Here are the seven most common ones and exactly how to close them before they cost you a project.
Whether it's an internal tool for your company or a highly available Software-as-a-Service - we help you to get your ideas off the ground!