Build vs. Buy: When Custom Software Is the Only Option
The default answer is buy. SaaS is cheaper, faster, and somebody else maintains it. But there are three conditions where buying creates more problems than…
The default answer to build vs. buy should always be buy. SaaS is cheaper upfront, faster to deploy, and somebody else handles maintenance, security patches, and uptime monitoring. For commodity workflows like email, calendars, file storage, and basic project management, buying is correct every time. The build impulse for these workflows is ego, not strategy. But there are three conditions where buying creates more problems than it solves. If the process you are automating is the thing that differentiates your business from competitors, outsourcing it to a vendor means outsourcing your differentiation to a tool that your competitors can also buy. A SaaS tool that does a large share of what you need does a large share of what everyone needs. The 20 percent gap is where competitive advantage lives. We see this most often in revenue operations. Companies buy a CRM, configure it for their sales process, and then discover that the CRM's data model does not match their commercial model. The integration work to bridge the gap costs more than building the workflow from scratch would have. The CRM becomes a constraint disguised as a solution. Modern organizations run 50 to 200 SaaS tools. Each tool solves one problem well. The problem is that business processes span multiple tools. A customer onboarding workflow touches the CRM, the billing system, the support platform, the product analytics tool, and the document management system. Each integration is a custom engineering project with its own failure modes, its own rate limits, and its own changelog that can break things without warning. When connecting five tools requires more engineering effort than building the workflow natively, the total cost of ownership for the buy decision exceeds the build decision, usually by the second year. The initial deployment is faster with SaaS. The ongoing maintenance is cheaper with custom software that owns its own data model. If a single vendor controls a critical business process and their pricing model changes, their roadmap diverges from your needs, or their company gets acquired, you have created a single point of failure in your operating model. The precedent exists. Salesforce pricing increases have repriced entire revenue stacks. Heroku's deprecation of free tiers displaced thousands of applications. Twilio's SendGrid acquisition changed the economics of transactional email overnight. Strategic risk tolerance varies by company. A startup with 18 months of runway should buy everything. A $50M company with a five-year horizon should own the systems that are core to its competitive position. The question is not build vs. buy. It is: where does the complexity live? If the complexity is in the workflow logic itself (the business rules, the decision paths, the data transformations that make your process different from a generic version), build. You are paying for commodity infrastructure to run custom logic. That is the right trade. If the complexity is in the infrastructure beneath the workflow (authentication, storage, email delivery, payment processing), buy. Building infrastructure that already exists as a service is vanity engineering. The commoditization of code has shifted the breakeven point. Three years ago, building custom software required a team of five and six months. Today, a two-person team with agentic development tools can ship a custom workflow application in four weeks. The build option is no longer the expensive option. Building now requires more judgment about what is worth owning.