# When to Build vs. Buy: A Framework
The first question we ask every prospective client is not "what do you want to build?" It's "are you sure you need to build this?"
We're a software development firm. Our revenue comes from building software. This question costs us work sometimes. We ask it anyway because giving clients honest advice is worth more long-term than maximizing short-term project scope.
The build vs. buy decision is one of the most consequential choices a growing business makes about technology. Getting it wrong in either direction is expensive.
The Case for Buying
Off-the-shelf software exists because there are common problems that most businesses share. A point-of-sale system. A CRM. An email marketing platform. Accounting software. HR management tools.
These products work because the underlying problems are well-understood, the requirements are broadly similar across customers, and years of iteration have produced mature, reliable solutions.
Buy when:
The problem is generic. If your requirements are substantially similar to what most companies in your space need, there's a good chance someone has built a product that covers 80-90% of them. The remaining 10-20% gap can usually be closed with configuration, integrations, or process adjustment.
Vendors are established and stable. A vendor with 10,000 customers, ten years of history, and a funded roadmap is a more reliable solution than custom code that becomes a maintenance liability.
Time-to-market is critical. Implementing a SaaS product in three months beats building custom software over nine months, even if the custom software would eventually be better.
Your team doesn't have the capacity to maintain custom software. Software you build is software you own forever. If your organization doesn't have the engineering resources to maintain it—fix bugs, update dependencies, add features, handle incidents—you're accumulating technical debt with every month it runs unattended.
The Case for Building
Custom development makes sense when your requirements genuinely can't be met by existing products—or when the core system is a competitive differentiator that you don't want to depend on a vendor for.
Build when:
The problem is genuinely unique. If your business operates a process that is specific to your industry, your scale, or your operating model—and no vendor has addressed it—custom development may be the only path.
It's your core competitive advantage. If the software is what makes you different—the algorithm that prices your services, the platform that your customers use directly, the workflow engine that makes you more efficient than competitors—you probably shouldn't outsource the roadmap and infrastructure to a vendor.
Existing products create dangerous dependencies. Some vendors lock you in deeply—proprietary data formats, opaque pricing that can escalate unexpectedly, APIs that limit what you can build on top. If a vendor owns something mission-critical to your business, they have leverage over your business. For certain categories of software, building avoids that leverage.
The total cost of adaptation is too high. Sometimes, bending a packaged product to fit your requirements costs more than building something fit-for-purpose. This happens when requirements diverge significantly from what the product was designed for, forcing heavy configuration, custom integrations, or process changes that the organization resists.
The Hidden Costs That People Miss
### Hidden costs of buying
Licensing at scale. Per-seat or per-transaction pricing looks cheap at 10 users and expensive at 1,000. Model the cost at 3x your current usage before committing.
Integration costs. Every vendor product you add creates integration overhead. Each product needs to connect to others, and those connections require maintenance. A five-vendor stack has up to ten integration surfaces, each of which can break.
Customization limits. SaaS products are designed for the median customer. The further your requirements deviate from the median, the more you're fighting the product instead of using it.
Vendor dependency risk. Acquisitions, pricing changes, product pivots, shutdowns—every vendor is a risk. Mission-critical systems that run on a single vendor are exposed if that vendor has problems.
### Hidden costs of building
Ongoing maintenance. Custom software requires continuous maintenance. Dependencies get outdated. Bugs surface. Infrastructure needs updates. The cost of maintenance over three years often equals or exceeds the initial build cost.
Knowledge concentration. If the engineers who built your system leave, the knowledge leaves with them—unless documentation is exceptional. Most documentation is not exceptional.
Opportunity cost. Engineering resources spent maintaining a custom payroll system are not spent on features that differentiate your product. Maintenance competes with innovation for the same engineering capacity.
Underestimated complexity. What seems like a two-month project frequently becomes a six-month project when the edge cases, integrations, and operational requirements are fully understood. This is a bias problem in human estimation, not a project management failure.
A Decision Framework
Before committing to build or buy, answer these questions:
1. Does a product exist that covers 80% of our requirements? If yes, map the gap. If the 20% is non-negotiable and can't be addressed through configuration or integration, continue. If the 20% is "nice to have" or can be accommodated through process adjustment, buy.
2. Is this system core to our competitive differentiation? If the system is a generic business operation (HR, accounting, basic CRM), it's probably not differentiated. If it's what makes your business work differently than competitors, it might be.
3. Do we have the internal capacity to maintain custom software? Be honest. If the answer is no and you're not planning to build it, factor ongoing external maintenance cost into the build option.
4. What's the total 3-year cost of each option? Build: development + ongoing maintenance + hosting + incident response Buy: licensing at scale + integration costs + customization costs
Run the numbers honestly for both. The "cheaper" option often isn't when you include everything.
5. What's our risk tolerance for vendor dependency? If the system is mission-critical and vendor pricing, availability, or stability concerns you, that's a factor in the build direction.
Our Recommendation
Most small businesses are better served by buying commodity software and building only what's genuinely unique. The overhead of maintaining custom software is real, and most of the underlying business functions—finance, HR, marketing, sales, customer support—are well-served by established products.
Where custom development makes strong sense:
- Your customer-facing product (if you're a technology business)
- Core operational systems that are genuinely specific to your business model
- AI and data systems that depend on your proprietary data
- Integrations between systems when no suitable integration product exists
Where you should buy:
- Everything your back-office runs on that isn't unique to your business
- Infrastructure you don't have the expertise to manage (use cloud services)
- Any category where a reliable, well-priced vendor exists
The honest answer is almost always "build some things, buy others." The skill is knowing which is which.