For most of the last decade, if a finance leader wanted Salesforce opportunities to flow into NetSuite as projects, and project status to flow back into Slack channels, the recommended architecture was a middleware platform. Workato, Mulesoft, Boomi, and a handful of others were the default answer. The pitch was straightforward. Pre-built connectors. Visual mapping. Enterprise governance. No code.
The pricing was also straightforward. A mid-market deployment landed somewhere between $50,000 and $200,000 per year, depending on connector count, recipe complexity, and whether you wanted the production-grade tier with audit logs and SSO. For a publicly traded company with 200 integrations and a regulated audit trail, that math worked. For a 60-person professional services firm with seven integrations, it did not.
What Actually Changed
Three things changed in the last 18 months that flipped the build versus buy calculation for most mid-market integration work.
First, edge compute got cheap and good. Cloudflare Workers, AWS Lambda, and similar serverless platforms can run integration glue code for cents per million invocations. A typical integration that fires 5,000 times per day costs less than $5 per month to host. The infrastructure is no longer a meaningful line item.
Second, the SaaS APIs themselves matured. Salesforce, NetSuite, HubSpot, Slack, QuickBooks, Lawcus, RingCentral, and the long tail of business systems all expose well-documented REST and GraphQL endpoints. Webhooks are standard. OAuth is standard. The connector that Workato spent five years polishing now takes a senior engineer a few days to write directly.
Third, AI orchestration entered the picture. An Anthropic-orchestrated agent can reason about a Salesforce opportunity, decide whether it should become a NetSuite project or a NetSuite sales order, draft the right payload, and post a clarification message to Slack when the answer is ambiguous. Middleware platforms are still working on retrofitting this. The new architecture starts with it.
The Architecture in Practice
The pattern we deploy most often has four pieces. None of them are exotic.
The trigger layer is webhooks plus polling. Salesforce fires a webhook when an opportunity hits closed-won. NetSuite is polled every five minutes for new project status changes because the NetSuite webhook coverage is uneven. Slack receives outbound messages but rarely triggers anything. This layer lives entirely on Cloudflare Workers and costs essentially nothing.
The reasoning layer is a small Anthropic Claude prompt with the relevant context, the desired output schema, and the rules for handling exceptions. When a closed-won opportunity arrives, the prompt receives the opportunity record, the account record, and the firm's rules about which opportunities map to which NetSuite project templates. It returns either a structured payload or a structured exception with a reason.
The reasoning layer is what middleware platforms cannot match. A Workato recipe handles the rule "if amount is over $50,000 and contract type is multi-year, create a Phase 1 project." It does not handle "look at the opportunity description, figure out which of our 14 project templates it most closely matches, and ask in Slack if you are not sure."
The execution layer is direct API calls to the destination systems. NetSuite has a SuiteTalk REST API. Slack has a chat.postMessage endpoint. The Worker fires the calls, captures the responses, and writes a record to a small audit log database (D1 on Cloudflare, or Postgres if the volume warrants it).
The observability layer is the part that surprises people. Because the entire pipeline runs on infrastructure we control, every transaction is logged, every payload is searchable, and every error surfaces in a Slack channel within 30 seconds. The audit trail is better than what most middleware platforms produce, because we built it for the specific integrations rather than the lowest common denominator.
The Cost Math
For a mid-market firm with seven integrations, the comparison looks like this.
Build cost for a typical seven-integration deployment runs $25,000 to $60,000 depending on the complexity of the systems involved. Annual run cost lands between $2,400 and $6,000 inclusive of model usage. The ongoing maintenance cost is what people overestimate. SaaS APIs change, but they change predictably and slowly. A monitoring layer that catches schema drift and a quarterly review keeps the system stable.
Compare that to a Workato or Mulesoft deployment of equivalent scope. Initial setup with a partner runs $40,000 to $100,000. Annual platform fee runs $50,000 to $150,000 depending on connector count and recipe volume. Even before counting the platform fee, the build cost is comparable. The difference is that the middleware platform charges you again every year for software you have already integrated.
When Middleware Still Wins
Custom is not always the right answer. Three scenarios still point to middleware.
Highly regulated industries with prescribed tooling. If your auditors require a SOC 2 Type II certified integration platform with documented change management, and your finance team is allergic to anything that smells custom, a Workato or Mulesoft deployment is the path of least resistance. The platform fee buys you a third-party stamp on the architecture diagram.
50 or more active integrations. The economics shift when integration count goes up. At 50 integrations, the per-integration cost of a middleware platform competes with the marginal cost of a 50th custom Worker. The visual recipe builder also matters more when you need a non-engineering team to maintain the catalog.
Complex transformation requirements with no AI fit. Some integrations are pure data plumbing across formats and protocols. EDI to JSON. SOAP to REST. CSV to NetSuite. AI reasoning adds nothing to those flows. A platform with battle-tested transformation libraries earns its keep here.
How to Decide
The simple version of the test is integration count and reasoning content. Under 15 integrations and meaningful reasoning content (judgment calls, exception handling, classification), custom wins on both cost and capability. Over 50 integrations and minimal reasoning, middleware is still the right answer. The middle is judgment.
The harder test is whether your team has access to a partner who can deliver and maintain the custom build. Middleware platforms exist partly because most firms cannot find or afford an integration team. If you have that team, custom is faster and cheaper. If you do not, the platform fee is buying capacity you do not have internally.
For a deeper walk-through of the integration architecture we deploy under the hood of a unified operations dashboard, see our unified operations dashboard page. For the related case where a CRM stack felt broken because the integration layer was missing, see The CRM Is Not Broken, the Stack Is.
The middleware era is not over. The default has changed.