Build vs buy, defined in one sentence
Buy means renting capacity per seat or per use, paying as long as you need the service. Build means owning the code, either custom-written or assembled from open-source components. The cost structures move in opposite directions: subscriptions start cheap and scale with usage; builds cost more upfront and become cheaper per task as volume grows.
Most businesses end up doing both. The question is not which is better in the abstract. It is which fits each specific function, at your current volume, with your current team capability.
Why the question matters now
SaaS costs are rising faster than usage. The bill is no longer driven by adding seats. It is driven by consumption pricing, AI add-ons, and stealth price increases at renewal. For automation tools specifically, per-task and per-credit billing means your costs scale every time your business grows, even if nobody new joins the team.
The pricing figures above come from the Zylo 2026 SaaS Management Index and the accompanying SaaS pricing trends report. The waste figure is from Vendr's research on SaaS hidden costs.
Zylo's figures come from their enterprise customer base. They are directionally useful: spend rises faster than usage, and renewal surprises are common. But the figures reflect large-enterprise averages and should not be read as typical for a 20 to 50 person business.
The shift matters for automation specifically. Legacy SaaS pricing was per seat: ten users, ten seats, predictable. Modern automation tooling bills per unit of work: ten thousand tasks, ten thousand charges. That changes the build vs buy calculation at any meaningful volume.
The decision matrix
Four questions frame the decision: What does this cost over three years? How well does the tool fit your actual process? How much control do you need? Is this a core part of how you compete? If the last answer is yes, the rest of the analysis is secondary.
If it is a core business function, do it yourself, no matter what.Joel Spolsky, In Defense of Not Invented Here Syndrome (2001). The broader argument: outsourcing a core function gives competitors a structural advantage you cannot buy back.
| Dimension | Buy (subscription) | Build (custom or self-hosted) |
|---|---|---|
| Total cost of ownership | Low entry cost, scales with task volume | Higher upfront, low marginal cost at scale |
| Fit to your workflow | Designed for the general case, typically ~80% fit | Engineered for your exact process, 100% fit possible |
| Data and control | Vendor controls pricing, data retention, and roadmap | You own the code, the data, and every dependency |
| Is it core to how you compete? | Right call when it is NOT your differentiator | Right call when it IS your differentiator |
The matrix does not produce a single winner. A business can rationally buy its email platform (commodity, not a differentiator), build its order routing (high volume, custom logic, direct revenue impact), and self-host its automation engine (per-task billing becomes expensive at scale). Each decision stands on its own.
A total-cost-of-ownership worked example
The crossover between cloud-billed automation tools and a self-hosted alternative depends on monthly task volume. At low volume, a subscription is cheaper than the overhead of owning infrastructure. As volume grows, per-task or per-credit billing starts to outpace the flat cost of a server running the same work for nothing.
All figures in the table below are illustrative, as of June 2026. Vendor pricing changes frequently and tiers vary by plan. Use these numbers to see where crossover typically occurs, not as a buying quote. Verify current pricing directly with each vendor before making any decision.
| Monthly tasks | Zapier (per task) | Make.com (per credit) | n8n Cloud (per execution) | n8n Self-hosted (Community) |
|---|---|---|---|---|
| ~500 tasks/mo | Professional from $19.99/mo | Per-credit billing: see make.com/en/pricing | Illustrative: ~$20/mo | $0 code + ~$5-10/mo hosting |
| ~5,000 tasks/mo | Illustrative: ~$100+/mo | Grows with each module action | Illustrative: ~$60/mo | $0 code + ~$5-10/mo hosting |
| ~20,000 tasks/mo | Illustrative: ~$400+/mo | Grows with each module action | Illustrative: ~$100/mo | $0 code + ~$5-10/mo hosting |
Zapier bills per task, with Professional starting at $19.99 a month. Make.com bills per operation credit: each module action in a workflow consumes one credit. n8n's Community Edition is the free, self-hosted version. You pay for the server, not the executions. As volume grows, per-unit cloud billing diverges sharply from the flat cost of self-hosted infrastructure.
The crossover varies by workflow complexity and vendor tier, but the direction is consistent: below a few hundred tasks a month, a subscription is the sensible call. Above a few thousand, the math starts favoring self-hosted. Above tens of thousands, it is rarely close.
When buying the subscription is the right call
Buy when the function is commodity, your volume is below the crossover point, the vendor handles compliance you would otherwise have to build, or the category is evolving fast enough that owning the code would mean chasing a moving target. A framework that always recommends building is selling you something.
This section is mandatory because balance is the credibility test. There are real categories where buying the subscription is clearly the right answer, and treating every function as a build candidate is a different kind of mistake.
- The function is commodity: every business does it the same way (email, calendar, accounting, payroll, document signing).
- Your volume is low: below the crossover point, per-unit cloud billing costs less than the overhead of owning infrastructure.
- Compliance is handled by the vendor: data residency, certifications, audit trails, and SOC 2 coverage you would otherwise have to build from scratch.
- The category is evolving fast: buying a subscription lets you change tools when the market moves; owning the code means you own the migration problem too.
- You do not have in-house capability to build and maintain it: a custom system without a permanent owner is a liability, not an asset.
Speed to capability is also a real factor. If you need a working process this week and the alternative is a build that takes eight weeks, the subscription wins on time, even if the three-year economics favor building. Builds require front-loaded investment before they deliver value.
When owning the code is the right call
Build when the function is core to how you compete, when task volume makes per-unit billing expensive, when you need data control a vendor cannot provide, or when the off-the-shelf tool handles 70% of your logic and the remaining 30% is load-bearing. That last 30% is usually where competitive advantage lives.
Volume is the most objective trigger. A workflow that fires thousands of times a month at cloud billing rates adds up fast. The same workflow on n8n Community Edition costs the same whether it fires five thousand or five hundred thousand times. The marginal execution cost is zero.
The 37signals case is instructive but not a like-for-like comparison. They moved servers off managed cloud, cutting their bill from $3.2M to $1.3M a year and projecting $10M+ in savings over five years. That required an in-house infrastructure team capable of owning those systems. It was an IaaS move, not a SaaS-to-custom-code move. The lesson applies only if you have the engineering capability to own what you build.
Integration depth is the second signal. Off-the-shelf automation tools are designed to connect popular apps. When your logic involves internal databases, proprietary APIs, or multi-step conditional routing that does not fit a drag-and-drop canvas, you spend more time fighting the tool than building the process. A custom build is designed around your data model.
Data control is the third. If you handle client data with sensitivity requirements, owning the infrastructure keeps data inside your perimeter. Cloud billing tools log every execution on infrastructure you have no visibility into. For some industries and some clients, that is the deciding factor before cost enters the conversation.
The hidden costs people forget on both sides
Subscriptions hide waste, unplanned price increases, and lock-in. Builds hide the cost of the engineer who leaves, the documentation nobody wrote, and the months it takes to add a feature you assumed would be simple. Neither path is cost-transparent by default.
On the subscription side, Vendr's research found companies waste more than $135,000 a year on unused or duplicate SaaS. Tools bought for a single project stay on the invoice long after the project ends. The 2026 Zylo SaaS Management Index found 79% of IT leaders saw renewal price increases, while 78% were hit by charges from AI or consumption add-ons they did not anticipate.
On the build side, the real cost is usually not the build itself. It is what comes after: the engineer who leaves taking institutional knowledge with them, the integration that breaks when an upstream API changes without notice, and the month-long detour to add a feature that should have been straightforward. Every custom system needs a permanent owner.
The honest comparison is not subscription cost versus build cost. It is total cost over three years: renewal increases, the percentage of the tool you actually use, the switching cost if the vendor changes terms, and the ongoing maintenance burden of keeping a build healthy. Run that number for each candidate before deciding.
The FIZI case study shows this decision applied to a real wholesale order management problem: a manual process replaced by a custom implementation, with the economics and tradeoffs documented. It is a useful read before any make-or-buy conversation.
Frequently asked
Q.How do I calculate the break-even point between a subscription and a build?
Compare total cost over three years. Take the current subscription cost, project forward with the renewal increases you have seen, and add the switching cost if you decide to change vendors. Compare that to an estimated build cost plus 15 to 20% per year for maintenance. When the subscription total exceeds the build total before 36 months, building deserves serious analysis.
Q.Does building require a full engineering team?
Not necessarily. Some automation builds use open-source workflow engines that a single integration engineer or technical generalist can manage. What you need is someone with enough technical ownership to maintain the system, update it when APIs change, and extend it when requirements shift. A build without a permanent owner is a liability, not an asset.
Q.Is a self-hosted automation tool really free?
The software is. n8n's Community Edition carries no per-execution charge. You pay for the server, typically a few dollars to around $20 a month depending on load. The real cost to factor in is the time to set it up, monitor it, and keep it updated. At high task volumes, that total is usually a fraction of equivalent cloud-billed costs.
Q.What about vendor lock-in? Does building avoid it?
Both paths create lock-in, just differently. Subscriptions lock you in through data formats, deep integrations, and team habits. Builds lock you in through institutional knowledge and proprietary logic. The key difference is who controls the exit: with a build, you own the code and can migrate on your timeline; with a subscription, the vendor sets the terms.
Q.We already have the subscription. Is it too late to switch?
No. The best time to evaluate is at renewal, before you sign another year. Run the three-year cost comparison, check whether you are using more than 70% of what you are paying for, and assess whether your volume has crossed the crossover point since you last decided. An operations audit can surface those numbers before the renewal date. See how we approach it at /audit.
