Most companies frame software decisions as build versus buy. That framing leaves out the option that has quietly become the most common: assemble. Buy three platforms, glue them together with a few automations, ask a contractor to fill the gaps, repeat for a decade. Nobody picks this architecture. It accumulates. By year five, it is the most expensive setup money can buy — and nobody decided on it.
There are really three categories of business software, and each one behaves very differently over the long term. The first is SaaS — the platforms you log into, paid per seat, owned and operated by someone else. The second is the new wave of automation and AI agent tooling that sits on top of SaaS — Zapier, Make, n8n, Lindy, and the long tail behind them. The third is custom software running on infrastructure you control. What follows is an honest comparison: where each one fits, where each one fails, and what changes over five years depending on which one your operational data sits inside.
SaaS is the default. Pick the popular tool, pay per seat, train your people, integrate with a few others. The promise is real: capability tomorrow morning, no engineers needed, a predictable monthly bill. For peripheral functions — payroll, ticketing, expense reports — the deal is usually fair, and the cost of switching stays survivable.
The trouble starts when SaaS is the home of your operational data. The sales pipeline. The service history. The contracts. The notes about every conversation with every client. Once the spine of the business sits in someone else's database, every decision they make becomes leverage you cannot answer. In August 2023, Salesforce ended a seven-year price freeze with a 9% list-price increase across the board. In March 2024, HubSpot moved to a new seats model that for many existing customers meant five-to-twenty times the cost for the same features. After Broadcom acquired VMware, AT&T was quoted a 1,050% renewal increase and ended up suing. These are not edge cases. They are the model. SaaS economics depend on raising the cost of leaving as fast as the cost of staying.
The newer category is what gets sold under labels like "AI automation", "no-code workflows", or "agent platforms". The pitch is straightforward: stop hiring engineers, connect the platforms you already pay for, sprinkle a model on top, watch the work do itself. For one-off connections, the category earns its place. The structural problem is what happens when these tools become the load-bearing logic of the business. They are SaaS sitting on top of SaaS. When the platform underneath changes its API, the glue breaks. When the glue platform changes its pricing, the cost moves with it. In January 2024, Zapier cut its free tier from 750 tasks to 100 and added a 1.25x premium on over-limit usage. In Q4 2024, n8n moved to execution-based pricing; a polling trigger that ran every five minutes suddenly burned through quota in days. In August 2025, Make.com switched from operations to credits, and credits weighted AI modules differently from the rest. None of these were destructive on their own. They each broke other people's workflows on someone else's schedule.
The cleanest illustration of the deeper risk is Twitter. In February 2023, the free API tier disappeared with a week's notice. Tweetbot and Twitterrific shut down. Within eighteen months, Microsoft, Sony, and Nintendo had each removed Twitter sharing from Xbox, PlayStation, and Switch. Three of the largest gaming companies in the world were renting an integration. They had no choice but to drop it. The lesson is not about Twitter. It is about what it means to put a critical business function on rails owned by someone whose interests are not yours.
The third category is custom software running on infrastructure you control. What that does not mean: an agency built you a portal. What it means: the database holding your operational data is yours, the applications reading from it are replaceable, and the servers running it are in a jurisdiction you chose. If the agency disappears, the system does not. If a tool above the data layer needs replacing, you replace the tool, not the data. This is not a new idea. It is how serious businesses ran their core systems before the SaaS era, and the reason a number of them have started moving back. The most public example is Amazon Prime Video. In 2023, the team running Prime's video quality monitoring published the result of moving one service from a microservices-and-managed-functions architecture back to a single owned component: a 90% reduction in infrastructure costs. The lesson buried in the headline is not that monoliths beat microservices. It is that owning the architecture beats renting it, once the system matters enough to your business.
Custom software has its own failure modes. The Standish Group's long-running CHAOS report puts overall software project success around 31%, with small focused projects clearing 90% and large enterprise rewrites under 10%. The pattern matters: the way to make custom software work is to build narrow systems that do real work, not to attempt a single platform that replaces everything at once.
Picture the same Belgian SME making three different choices in 2021, and look at what each one looks like in 2026. The SaaS-first company is paying for between forty and a hundred separate platforms. BetterCloud's 2024 SaaSOps survey puts companies in the seventy-five-to-two-hundred employee bracket at forty-four SaaS apps on average; companies between two hundred and seven hundred fifty employees at ninety-six. Their data is split across all of them. The CRM has the contacts. The accounting tool has the invoices. The helpdesk has the tickets. None of them talk to each other without an integration tax. Each renewal is a separate negotiation in someone else's favor.
The automation-first company is paying for the SaaS underneath plus the automation layer above. The dashboards work today. The agents respond to events today. Every quarter, two or three workflows quietly stop working because someone — Salesforce, HubSpot, Microsoft, the agent platform — pushed an update. The team spends real hours rebuilding glue. The custom-first company is paying for less software, but for an engineering team or partner. The data is in one place. New applications get added on top of the same data layer. When a vendor changes terms, the company replaces a tool, not a database. After five years, the data is worth something. After ten, it is one of the most valuable assets the company holds, and nobody else has a copy of it.
Most companies do not actually pick one of the three. They end up with all three: SaaS at the core, automation tools wrapped around it, and a custom portal some agency built in 2021 that nobody has touched since the developer stopped answering emails. This is the most expensive of the four possible outcomes — including not having software — because the costs of all three categories compound at once. The reason it happens is that nobody makes the architectural decision. Sales picks Salesforce because that is what sales picks. Operations picks Make.com because operations needed something fast. The CEO commissions a custom dashboard because the SaaS tools cannot show what the CEO actually wants to see. Each individual choice is reasonable. The result is unmanageable.
There is no honest version of this argument that ends with "always pick category three." Each of the three categories is the right choice for a specific kind of work. SaaS is the right choice for functions that are not your operational core, where you would genuinely change your process to match the tool, and where the data inside it is mostly disposable. Time tracking. Email marketing. Document signing. Helpdesk for non-technical issues. Pick the popular tool, accept the lock-in, and reconsider every three years.
Automation tooling is the right choice for prototypes and one-off integrations. Build the workflow, treat it as disposable, expect to rebuild it within a year. Do not let it become the place a critical business rule lives. If a workflow is too important to lose, that is a signal the rule belongs in code your team owns, not in someone else's drag-and-drop canvas. Custom software on owned infrastructure is the right choice for the systems your business actually runs on. The CRM if relationships are the core of your business. The ERP if execution is. The dispatcher if your field team cannot work without it. The systems whose failure would stop the business — those are the ones worth owning.
A useful question to ask about each tool currently inside the business: if the vendor changed the terms tomorrow, would the business stop, slow, or barely notice? Things in the "stop" column should be category three. They are the load-bearing systems. They should be on infrastructure the company controls, with a database the company owns, and applications that can be replaced without disturbing the data. Things in the "barely notice" column can stay in category one. The lock-in does not matter because the dependency is shallow. The dangerous middle — "slow" — is where most companies end up putting things they should not have. The CRM with five years of contact history. The accounting tool whose ledger is the financial record of the business. The dispatcher the field team cannot work without. These are stop-column tools that the business has accidentally treated as barely-notice ones.
The choice that compounds is not which CRM, which automation tool, or which custom build. It is which architecture the business sits on top of for the next ten years. Most companies are making that choice without realising it — by inertia, vendor by vendor, integration by integration. Make the decision once, deliberately. Decide which functions belong in category one, which experiments are worth keeping in category two, and which systems are core enough that the data and the architecture should be yours. The companies that do this stop spending the second half of every decade unwinding the first half.
