Revenue Engineering

When to Stop Buying SaaS and Build the Integration Layer

You bought five products and now you are building all the connections anyway. The four signals that it is time to own the layer between them, and what owning it actually means.

Mauricio Esparza By ·Published ·2 min read
mithub.club
Short answer

Build the integration layer when four things are true: you own more than four systems that must share data, the same data is entered twice somewhere, at least one connection is a person copying values, and the cost of your automation platform now tracks volume rather than value. Owning the layer does not mean writing everything from scratch. It means the logic that connects your systems is yours, documented, and not held inside a product you rent.

There is a moment every growing company reaches and nobody warns them about. You bought the CRM, the billing tool, the support tool, the analytics tool and the scheduler. Each decision was right on its own.

And now none of them talk to each other, so you are building the connections anyway.

You did not buy a solution. You bought five products and the job of connecting them.

The four signals

1. More than four systems have to share data. Below that, point to point connections are manageable. Above it, the number of possible connections grows faster than anyone's ability to remember them.

2. The same data is entered twice. Anywhere. It means the connection does not exist and a person is the connection.

3. At least one connection is a human copying values. This is the clearest signal because it has a salary attached to it.

4. Your automation bill tracks volume rather than value. Per task pricing is comfortable at hundreds of runs and uncomfortable at hundreds of thousands. When the invoice grows with activity rather than with results, the model no longer fits you.

What owning the layer actually means

It does not mean writing everything from scratch. It means three things:

The logic is yours. The rules about what happens when a lead arrives, how records are matched, what to do when a field is missing. Written down, in your words, outside any tool.

It is portable. If you changed platforms tomorrow, the rebuild would be mechanical rather than archaeological. This is the practical test, and most teams fail it.

It has an owner. A named person, not a team and not a vendor.

The layer itself can live on an automation platform you self host. Self hosting stops the cost tracking executions and keeps records in your infrastructure, in exchange for owning updates, backups and uptime. If nobody will own a server, do not self host, whatever the saving looks like.

What to bring in house first

The connection a person currently performs by hand. It has an obvious cost, an obvious owner and an obvious definition of done.

Not the most complex integration. Not the most interesting one. The one with a salary attached.

What to keep buying

Everything undifferentiated and mature: email infrastructure, calendars, payments, enrichment sources, calling infrastructure, the CRM itself. Building these spends your scarcest resource on a solved problem.

What you own is the logic between them, which is the part that encodes how your business actually works and the part no product will ever model correctly.

How not to build a monolith

One flow per job, each with its own trigger and its own failure. The alternative, a single integration that does everything, fails entirely when it fails and becomes the thing nobody will touch.

Every flow needs an error route, because what has no error route fails in silence. And the layer needs monitoring that alerts on absence, not only on errors, since a flow that stops running produces no errors at all.

The question that settles it

If you changed automation platforms tomorrow, how much of your business logic would you have to rediscover by reading old workflows?

If the answer is most of it, you do not own your integration layer. You are renting it, and the rent goes up with your volume.

Frequently asked questions

Does this mean writing code?

Not necessarily. Owning the layer means owning the logic and the documentation, which can live on an automation platform you self host. The distinction is whether the logic is yours and portable, not whether it is code.

What is the first thing to bring in house?

The connection that a person currently performs by hand, because it is the one with an obvious cost and an obvious owner. Start there rather than with the most complex integration.

What if a vendor offers a native integration?

Use it where it does what you need. Native integrations are excellent at the common path and usually silent about your exceptions, which is where the layer you own earns its place.

How do we avoid building a monolith?

One flow per job, each with its own trigger and its own failure. A giant integration that does everything fails entirely, and it becomes the thing nobody is willing to touch.

Sources

  1. Handle errors gracefully · n8n Docs (accessed 2026-09-22)
  2. Self-hosting n8n · n8n Docs (accessed 2026-09-22)
  3. Why evaluate AI workflows · n8n Docs (accessed 2026-09-22)
Revenue EngineeringArchitectureProcurement
Mauricio Esparza
Mauricio EsparzaGTM Systems Lead · Revenue Engineer · Founder of MitHub. Designs and runs revenue systems for multi-location businesses: AI voice campaigns, enrichment, CRM automation and attribution. Founded MitHub to teach the method in the open.

Part of Revenue Engineering on MitHub.

Keep going

GTM Engineering

Build or Buy: GTM Automation Decision Guide

When to buy a platform, when to build on an automation layer, and when to hire someone to own it. The costs each option hides and the questions that decide it.

Read · 2 min →mithub.club
n8n

Choosing an Automation Platform: n8n, Zapier or Make

A buyer's comparison of the three automation layers most revenue teams choose between, the cost model that decides it, and when self hosting is worth the operational burden.

Read · 2 min →mithub.club
Revenue Engineering

Who Owns an Automation After It Goes Live?

The question nobody answers when the build finishes: who monitors it, who fixes it when an API changes, who approves changes, and what happens when the person who built it leaves.

Read · 2 min →mithub.club
AI & Automation

What AI Automation Actually Costs to Run

The cost lines nobody models before launch: model usage, platform execution, telephony, enrichment, and the human time that does not disappear.

Read · 2 min →mithub.club
Revenue Engineering

CRM Architecture for Revenue Teams

How to design a CRM that survives contact with reality: objects, stages, fields, ownership and data contracts, with a stage test and an architecture review.

Read · 7 min →mithub.club
AI & Automation

When to Hire a Forward Deployed Engineer

The buyer's view of the forward deployed engineer: the problems that need someone embedded in your systems, how the engagement is scoped, and how to tell a real one from a consultant with slides.

Read · 3 min →mithub.club