Every organization eventually faces the build-vs-buy question. A process needs automating, a workflow needs tooling, a gap in the technology stack needs filling. Somebody raises the idea of building something custom. Somebody else suggests buying a product off the shelf. What follows is usually a debate driven more by gut feeling, internal politics, and whoever happens to be loudest in the room than by any structured analysis of the actual decision.
After 15 years of advising organizations through these decisions, the pattern is remarkably consistent: they default to "build" when they should buy, and default to "buy" when they should build. The reasons are predictable. Building feels innovative and exciting. It flatters the technical team and gives leadership the feeling of investing in something proprietary. Buying feels safe and fast; it offloads risk to a vendor and puts a purchase order on someone else's balance sheet. Both instincts are wrong about half the time.
The worst part is that organizations rarely revisit these decisions. A build commitment made in a two-hour meeting becomes a five-year maintenance burden. A buy decision made on the back of a persuasive vendor demo locks the organization into a platform that shapes its processes for a decade. The initial decision gets a few days of attention. The consequences play out over years.
The core question most people skip
Before you compare feature lists or estimate development timelines, you need to answer one question: Is this capability a genuine competitive differentiator for your organization?
This sounds simple. It is not. Most organizations dramatically overestimate how many of their processes are unique. Your accounts payable workflow is not a competitive advantage. Your HR onboarding process is not a competitive advantage. Your project management methodology, however beloved internally, is almost certainly not a competitive advantage.
A competitive differentiator means the process itself is part of what makes your organization win in the market. The way a logistics company routes shipments. The way a trading firm prices risk. The way a media company manages content workflows under live broadcast deadlines. If someone could replicate your process by buying the same software you use, it was never a differentiator it was an implementation detail.
If a competitor could achieve the same result by buying the same SaaS product you're considering, the capability is a commodity. Buy it. Spend your engineering effort on things that actually make you different.
The honest application of this test eliminates about 80% of build-vs-buy debates. Email, CRM, accounting, HR management, helpdesk, project management, document storage: these are commodity functions. There is no version of reality where building a custom CRM gives you a competitive edge. There is a version of reality where the two years you spent building one left you unable to invest in the thing that actually matters.
This test also exposes a common self-deception. Technical teams frequently argue that their requirements are "too unique" for commercial products. Press them on specifics and the uniqueness usually evaporates. They don't need a custom ticketing system because their support process is unique. They want a custom ticketing system because their current one is badly configured and nobody has invested the effort to fix it. Those are very different problems, and the second one doesn't require writing software.
When building is the right answer
Building custom software makes sense in a narrow set of circumstances, and organizations need to be honest about whether they actually meet the criteria.
Your process is the product. If the software you're building is directly tied to how you generate revenue (not support functions, but the actual mechanism of value delivery) then owning that capability makes strategic sense. A logistics company building its own route optimization engine. A financial services firm building its own risk modeling platform. A media organization building its own content management pipeline that handles live ingest, transcoding, and distribution under the timing constraints of a live broadcast. These are cases where off-the-shelf tools either don't exist, can't handle the specific requirements, or would give competitors the same capabilities.
The market genuinely doesn't have a solution. This is rarer than people think. Before concluding that nothing exists, you need to have actually looked. Not just Googled for 20 minutes, but done a proper market scan. Talk to vendors. Talk to analysts. Talk to peers in your industry. If three credible vendors offer products in the space, you don't have a "nothing exists" problem. You have a feature-gap problem, and that's a different discussion entirely.
Integration requirements are so specific that no product can accommodate them. This one is legitimate but frequently overstated. Most modern SaaS products have APIs. Most integration requirements can be met with middleware, iPaaS platforms, or custom API connectors. The question is whether your integration needs are truly beyond what can be achieved by connecting existing products, or whether you're using integration complexity as a justification for a build decision you've already emotionally committed to.
Regulatory or data sovereignty constraints prohibit third-party processing. Some sectors have genuine restrictions on where data can be processed and by whom. Defense, certain healthcare applications, financial clearing systems. There are legitimate scenarios where regulatory requirements make it impossible to use a multi-tenant SaaS product. But verify this with your compliance team and legal counsel before accepting it as a given. Organizations frequently over-interpret regulatory requirements because someone in a meeting said "I think we can't use cloud for that" and nobody checked.
The ERP trap: "configure don't customize" and other lies
Enterprise resource planning systems deserve their own section because the build-vs-buy dynamics are uniquely dysfunctional in this category.
The vendor pitch for every major ERP (SAP, Oracle, Microsoft Dynamics, NetSuite) includes a version of "configure, don't customize." The idea is sound: use the system's built-in configuration options to adapt it to your processes rather than writing custom code that will break on the next upgrade. In theory, this lets you benefit from the vendor's ongoing development while maintaining your specific workflows.
In practice, the distinction between configuration and customization is blurry, and implementation partners have a financial incentive to blur it further. A "configuration" that involves writing custom workflow rules, building bespoke reports, creating custom fields and entities, and writing JavaScript in form events is customization wearing a configuration hat. It will break on upgrades. It will require specialized knowledge to maintain. It will not be covered by standard vendor support.
The honest version of "configure don't customize" would be: "Bend your processes to fit the software's standard workflows wherever possible. Accept that the system will do things slightly differently than you'd prefer. Reserve genuine customization for the two or four areas where the standard approach truly cannot support your business requirements." That advice isn't as marketable, but it's the version that leads to sustainable ERP implementations.
The organizations that have the most painful ERP experiences are the ones that spent millions customizing the system to replicate their existing processes exactly. They ended up with a heavily modified version of SAP or Oracle that costs a fortune to maintain, can't be upgraded without a regression testing effort that takes months, and has drifted so far from the standard product that the vendor's own consultants struggle to support it. They would have been better off either adapting their processes to the standard product or building something purpose-fit from scratch. The middle ground (buy a platform and then customize it until it's unrecognizable) is the worst of both worlds.
The CRM decision and what it teaches about buy decisions generally
CRM systems are instructive because almost every organization faces this decision and almost every organization gets some part of it wrong.
The build-vs-buy answer for CRM is overwhelmingly "buy." Salesforce, HubSpot, Pipedrive, Microsoft Dynamics. The market is mature, the products are capable, and your sales process is almost certainly not so unique that it justifies custom development. The mistake organizations make isn't in the build-vs-buy decision. It's in the buy decision itself.
They buy Salesforce Enterprise when HubSpot Professional would have served them perfectly well. They buy Salesforce because "nobody gets fired for buying Salesforce," ignoring the fact that the implementation cost, ongoing administration overhead, and annual license fees for a full Salesforce deployment are wildly disproportionate to the needs of a 50-person company. Or they buy the cheapest option because the CFO balked at the Salesforce quote, and then spend two years fighting its limitations.
The real framework for a CRM buy decision (and this applies to any major platform purchase) has four steps. First, define your requirements honestly, based on how you actually work today, not how you'd like to work in some theoretical future. Second, evaluate at least four products across two different pricing tiers. Third, trial the shortlisted products with actual data and actual users, not just a sales demo. Fourth, calculate total cost of ownership over five years, including implementation, training, administration, integration, and the annual license increases that every vendor bakes into their contracts.
Most organizations skip steps two and four entirely. They see a demo, they like the demo, they sign. Two years later, they're locked in and unhappy, which is exactly where the vendor wants them.
The 80% trap
The most dangerous build-vs-buy scenario is the one that looks like a straightforward buy decision but isn't. It goes like this: you evaluate a SaaS product. It does 80% of what you need. The vendor assures you the remaining 20% is on the roadmap, or can be handled with configuration, or "most of our customers don't actually need that." You sign the contract.
Six months later, the 20% gap is still there. Your team has built workarounds: spreadsheets alongside the system, manual processes to cover the gaps, a small application that pulls data out of the SaaS product via API, transforms it, and pushes it into another system. You now have the worst of both worlds: a commercial product you're paying full price for, plus custom code that fills the gaps, plus the maintenance burden of both.
The 80% trap is where organizations hemorrhage time and money without ever making a conscious decision to do so. The workarounds accumulate gradually. Nobody ever formally approves the custom development because each piece is small enough to fly under the radar. But in aggregate, you've spent more on bridging the gaps than you would have spent on a purpose-built solution, and the result is more fragile than either option would have been on its own.
A specific variant of this trap involves vendor roadmap promises. "That feature is coming in Q3" is the most dangerous sentence in enterprise software sales. Sometimes the feature ships in Q3. More often it ships in Q1 of the following year, in a form that doesn't quite match what was described. Sometimes it never ships because the vendor's priorities changed. You have zero control over a vendor's product roadmap, and making a purchase decision based on features that don't exist yet is gambling with your operational capability.
The correct response to the 80% trap is to recognize it as a genuine decision point. If the product does 80% of what you need, your options are:
- Accept the 80% and change your process to match the tool. This is almost always the right answer for commodity functions. Your invoicing workflow does not need to be special.
- Buy the product and build a thin integration or extension layer to cover the gap. This works if the gap is clearly bounded, the product has a stable API, and you're willing to maintain the integration code indefinitely.
- Walk away from the product and build. This is the right answer if the 20% gap is in the area that makes the capability a differentiator if it's precisely the part where your process diverges from the industry standard.
- Walk away from the product and find a different product. This is the option people forget. Just because one vendor can't meet your requirements doesn't mean the answer is "build." It might mean you haven't looked at enough vendors.
What you must not do is buy the product while quietly planning to build around its limitations without accounting for the total cost of that approach.
The hidden costs of building
Organizations that choose to build consistently underestimate five categories of cost.
Ongoing maintenance. The initial build is the minority of the total cost of ownership. Industry data consistently shows that maintenance consumes 60-80% of the total lifecycle cost of custom software. The application needs patching, updating, and adapting as the business changes. Dependencies need updating (and modern applications have hundreds of dependencies, each with its own release cycle and security advisory stream. Frameworks release new versions. Node.js moves from v18 to v20 and your application's test suite breaks in ways nobody predicted. The cloud provider deprecates the API you built on. AWS alone deprecates dozens of services and API versions every year. None of this is optional, and none of it delivers visible business value) it's the cost of keeping the lights on for something you chose to own.
Security. Every custom application is an attack surface. It needs vulnerability scanning, penetration testing, secure coding practices, dependency monitoring, and incident response procedures. When a CVE drops for a library you depend on (and Log4Shell proved that a single library vulnerability can affect virtually every Java application on the planet) someone needs to assess the impact, apply the patch, test the fix, and deploy it. A SaaS vendor has a security team doing this full-time across thousands of customers, with automated dependency scanning, bug bounty programs, and SOC 2 certifications. Your internal team is doing it as a side task between feature requests, probably without automated tooling, and definitely without a bug bounty program.
Developer dependency. The developer who built the system has context that no one else has. They understand why that database schema looks the way it does, why that particular API endpoint has a 30-second timeout instead of the standard 10, why the batch process runs at 3 AM and not midnight, and why there's a commented-out block of code with the note "do not remove, breaks CSV export." When that developer leaves (and they will leave, because the average tenure for a software developer is about two years) that context walks out the door with them. Documentation helps, but documentation for internal tools is perpetually incomplete and perpetually out of date. The next developer who touches the system will spend weeks or months understanding it before they can safely change anything.
Opportunity cost. Every hour your development team spends maintaining an internal invoicing tool is an hour they're not spending on the thing that actually differentiates your business. This is the cost organizations find hardest to quantify, but it's usually the largest. The custom build doesn't just cost what you spent on it. It costs what you didn't build instead. A development team that's spending 40% of its time on maintenance of commodity systems has effectively lost 40% of its capacity for competitive investment. For most organizations, that math is devastating when you actually calculate it.
Scaling and reliability. A SaaS product handles its own uptime, scaling, backups, disaster recovery, and performance monitoring. A custom application puts all of that on you. Your application needs to handle traffic spikes, database growth, backup verification, and failover. You need monitoring and alerting. You need on-call rotation for when it breaks at 2 AM. You need a disaster recovery plan and you need to test it. Most internal teams design for current load, not for the load three years from now, and the rearchitecting that follows is expensive and disruptive. It's also the kind of work that no developer wants to do, which means it gets deferred until performance problems become user-visible, at which point you're in crisis mode.
The hidden costs of buying
The buy side has its own set of costs that organizations underestimate, and vendors work hard to obscure.
Vendor lock-in. The deeper you integrate a product into your operations, the harder it becomes to leave. Your data is in their schema. Your workflows reference their field names. Your integrations call their API endpoints. Your team has been trained on their interface. Your business processes have been adapted to match the tool's assumptions. Switching costs compound over time, and vendors know this: it's why the first-year price is always the best price. By year three, you're paying significantly more and your negotiating position has eroded because they know you can't realistically leave. The Broadcom acquisition of VMware demonstrated this perfectly: overnight, licensing models changed, prices increased dramatically, and organizations that had built their entire virtualization strategy around VMware had no short-term alternative.
Data portability. Can you get your data out? Not the polished export they show in the demo, but your actual data, with all the relationships and history intact, in a format you can use somewhere else. Most SaaS vendors will let you export a CSV. Few will give you a complete, relational export that preserves the full context of your information. Salesforce will export your records, but the relationships between objects, the file attachments, the audit history, and the custom metadata? That takes a specialized migration tool and significant effort. If you can't get your data out cleanly, you don't own it. You're renting access to it on someone else's terms.
Forced upgrade cycles. SaaS vendors ship updates on their schedule, not yours. Features you rely on get deprecated. Interfaces change overnight. New features you didn't ask for introduce complexity and retraining costs. Salesforce ships three major releases per year whether you're ready or not. Microsoft's pace of change in the 365 ecosystem means your internal documentation is out of date within months. You're on their roadmap, and their roadmap serves their entire customer base, not your specific needs. Enterprise customers get some influence here, but mid-market organizations are along for the ride.
Feature bloat and complexity tax. You're paying for the platform. You're using 30% of it. The other 70% adds complexity to the interface, creates confusion for your team, and occasionally introduces security surface area you didn't ask for. Every SaaS product accumulates features over time because the vendor needs to justify price increases and win competitive evaluations. The result is that simple products become complicated ones, and your team needs more training to use a tool that should be straightforward. The vendor won't give you a discount for using less; pricing is based on seats or revenue, not feature utilization.
The annual price ratchet. Almost every SaaS contract includes annual price increases. Some are tied to CPI. Some are a flat percentage. Some are "at the vendor's discretion," which means "whatever they think they can get away with." Salesforce routinely increases prices by 7-9% annually. Microsoft's 365 pricing has increased substantially over the past five years. These increases compound, and they're non-negotiable for most customers. Over a five-year period, a product that cost X in year one may cost 1.4X in year five, with no corresponding increase in the value you receive.
Integration debt: the cost nobody budgets for
There's a category of cost that sits between build and buy, and it's the one that causes the most damage: integration debt.
Integration debt accumulates when you buy five tools that each do their job well, but none of them share data without manual effort or custom glue code. The sales team uses one CRM. Finance uses a different accounting platform. Operations uses a project management tool. HR uses a separate HRIS. Customer support uses a helpdesk system. Each was chosen independently, each is good at its primary function, and none of them were evaluated for how well they integrate with the existing estate.
The result is data silos, duplicate entry, reconciliation headaches, and reports that require someone to pull data from four systems into a spreadsheet before anyone can answer a basic question about the business. This is the hidden cost of a "buy everything separately" strategy, and it's substantial. Organizations routinely underestimate how much time their people spend bridging gaps between systems that should talk to each other but don't.
An iPaaS platform (Workato, Make, Zapier at the lower end, MuleSoft or Boomi at the enterprise end) can handle straightforward integrations. But when the integration logic is complex (when data needs to be transformed, validated, enriched, and routed based on business rules that change quarterly) a custom integration layer often delivers better results than trying to express that logic in a visual workflow builder that was designed for simple triggers and actions.
The key insight: five best-of-breed tools connected by functioning integrations will outperform one monolithic platform that does everything adequately and nothing well. But five tools connected by nothing are worse than any single platform. And five tools connected by fragile, undocumented, unmaintained Zapier workflows built by someone who left the company two years ago are the worst option of all.
When evaluating any buy decision, the integration question needs to be part of the initial assessment, not an afterthought. How will this product share data with the systems it needs to connect to? Does it have a proper API, or just a CSV import/export? Is the API well-documented, versioned, and stable, or does the vendor break it with every release? What's the ongoing cost of maintaining the integration, and who owns it? These questions are as important as the feature comparison, and they're almost never asked during vendor evaluation.
The low-code/no-code problem
Low-code and no-code platforms deserve a specific callout because they are routinely mischaracterized in the build-vs-buy debate. Organizations adopt them thinking they're "buying" a solution. They are not. They are building on someone else's platform, subject to that platform's constraints, pricing, and continued existence.
This is a critical distinction. When a business analyst builds an application in Power Apps or Retool or Bubble, they are writing software. The fact that they're doing it with drag-and-drop components rather than Python doesn't change the fundamental nature of the activity. That application needs to be maintained, tested, secured, version-controlled, documented, and eventually replaced. The same obligations apply as with any custom-built software. The maintenance burden might be lower per application, but low-code platforms tend to produce large numbers of small applications, and the aggregate maintenance burden is significant.
The difference is that low-code applications tend to accumulate without governance. No one tracks them centrally. No one reviews them for security. No one ensures they're backed up or documented. A developer building a traditional application at least operates within the engineering team's processes: code review, version control, deployment pipelines, testing standards. A business analyst building a Power App operates outside those processes entirely, and the result is shadow IT with a Microsoft license.
Power Platform is the most common offender here because it's bundled with Microsoft 365 and most organizations already have it. The barrier to entry is zero, which means Power Apps proliferate. Some of them are useful. Some of them are critical. Some of them were built by someone who left, contain business logic that nobody else understands, process sensitive data without proper access controls, and would cause operational problems if they stopped working. And nobody in the IT department knows they exist.
Low-code platforms have legitimate uses. Rapid prototyping, internal tools with a short expected lifespan, simple workflows that would be overengineered as traditional code. But the maintenance burden is real, the platform lock-in is severe (try migrating a Power Apps application to anything else; the answer is you rebuild from scratch), and the "citizen developer" narrative systematically underestimates how much governance, testing, and lifecycle management these applications actually require.
If you wouldn't let an untrained employee write production code, think carefully about letting them build production applications in a low-code platform. The runtime is different. The risks are the same.
A practical decision checklist
When a build-vs-buy decision lands on your desk, work through these questions before anyone opens a code editor or schedules a vendor demo.
1. Is this capability a genuine competitive differentiator? Be ruthless. If a competitor could buy the same tool and achieve the same result, it's not a differentiator. Buy it.
2. Does a commercial product exist that covers at least 80% of the requirement? If yes, seriously evaluate whether you can adapt your process to fit the tool rather than the other way around. Process flexibility is cheaper than custom software.
3. If you build, who maintains it in year three? Not who builds it. Who maintains it after the initial developer has moved on, the business has changed, and the exciting greenfield project has become a legacy system. If you don't have a credible answer, you're not ready to build.
4. What is the total cost of ownership over five years? For a build: initial development, infrastructure, security, maintenance, developer retention, opportunity cost, disaster recovery, monitoring, on-call support. For a buy: license fees (assume annual increases of 8-12%), implementation costs, integration costs, training, process adaptation, ongoing administration, and switching costs if you need to leave.
5. What happens to your data if the vendor disappears or you need to leave? Test this before you sign. Request a full data export during the evaluation. If they can't provide one, or if the export is unusable without their platform, factor that risk into your decision. Ask for their data portability documentation in writing. If it doesn't exist, that tells you everything you need to know about how they think about customer data ownership.
6. How does this interact with your existing systems? A tool that solves one problem but creates an integration gap is not a net positive. Evaluate the system-level impact, not just the point solution. Map the data flows before you commit.
7. Is this actually a build-vs-buy decision, or is it a process design decision? Many build-vs-buy debates are really arguments about how the organization should work. The technology question is downstream of the process question. Settle the process question first. If you can't agree on the process, no technology, built or bought, will fix the problem.
8. Are you solving a current problem or a hypothetical future problem? Building for requirements you might have in two years is a reliable way to waste resources. Buy a tool that solves today's problem. Revisit the decision when the requirements actually change. Premature architecture is as wasteful as premature optimization.
9. What's the organizational risk tolerance for each option? Building carries execution risk: your team might not deliver. Buying carries dependency risk: the vendor might change direction. Both are real. Which one is more manageable given your current capabilities and situation?
10. Have you separated the decision from the decision-makers' preferences? Your CTO wants to build because building is interesting. Your CFO wants to buy because it's a predictable cost. Your operations director wants to keep using the spreadsheet they've had for five years. None of these positions are wrong, but none of them are decision frameworks either. The framework should produce the answer. Personal preferences should be noted and then set aside.
When the right answer is "neither"
Sometimes the most important outcome of a build-vs-buy analysis is realizing that you shouldn't be doing either. The requirement itself is wrong. The process you're trying to automate shouldn't exist in its current form. The problem you're trying to solve with technology is actually a people problem or a process problem that technology will only paper over.
Automating a broken process gives you a broken process that runs faster. Buying software to manage a workflow that shouldn't have seventeen approval steps doesn't fix the workflow; it institutionalizes the dysfunction. Before you build or buy anything, ask whether the underlying need is valid, whether the current process is the right starting point, and whether simplifying the process might eliminate the need for the technology entirely.
This is uncomfortable advice because organizations have usually invested significant emotional energy in the build-vs-buy debate by the time someone senior gets involved. Telling the team that spent two months evaluating CRM platforms that the real problem is their sales process, not their tooling, doesn't win popularity contests. But it's often the right answer, and it's the answer that saves the most money long-term.
The decision nobody wants to make
The hardest build-vs-buy decisions are not the ones where the answer is clearly "build" or clearly "buy." They're the ones where the honest answer is "neither option is great, and we need to pick the one that's least bad."
That's most of them. The commercial product doesn't quite fit. Building would take longer than you have. The integration between existing tools is fragile. The low-code prototype is already in production and nobody wants to rebuild it properly. These are the real-world conditions under which technology decisions get made, and pretending otherwise is how organizations end up with technology estates that look like they were designed by a committee of people who never talked to each other. Because they were.
The framework above won't make those decisions easy. But it will make them honest. And honest decisions, made with a clear understanding of trade-offs, costs, and risks, tend to age better than the ones driven by enthusiasm, vendor demos, or the assumption that building something custom will somehow be different this time.
Document the decision. Document the reasoning. Document the trade-offs you accepted and the risks you chose to carry. When you revisit this in two years (and you will) you'll want to know what you were thinking and why. That institutional memory is worth more than most organizations realize, and losing it is how the same bad decisions get made over and over again.