A fork in a service road at an industrial park seen from the driver’s seat, both directions equally plausible, no signage.

Four things move the line

Use the platform until one of four things happens.

Start on a platform. Move to a custom integration when one of four things happens: the step count passes roughly a dozen, silent failures start costing real money, the volume makes per-task billing bite, or the logic stops fitting a visual builder. Until then, a platform is faster and cheaper and we will say so.

Start on a platform. Almost always.

A platform gets a working connection in days rather than weeks, it costs less than any build, and — the part people underrate — you can see what it is doing. When it breaks, someone non-technical can open it and look.

That legibility is worth a great deal for a small business, and it is the main reason we recommend a platform even on engagements where we would be paid more to build. If a Zap solves it, a Zap solves it — the same position as custom vs off-the-shelf, arriving from the tooling end.

The four things that move the line

Any one of these is enough to make a build arguable. Two makes it obvious.

1. Step count past roughly a dozen Long chains in a visual builder become unreadable and untestable. The threshold is fuzzy, but you will feel it — the moment nobody wants to touch the workflow, you have crossed it.
2. Silent failure costs real money Platforms retry and log, but they are not built to reason about partial success. If half a job posting wrongly and nobody noticing costs you a customer, you need real error handling — and that is code.
3. Volume makes per-task billing bite Task-based pricing is fair and it rises with success. There is a crossover point where a small service on your own infrastructure is cheaper — <a href="/compare/zapier-vs-n8n">the cost curves are on the Zapier vs n8n page</a>.
4. The logic stops fitting the shape Loops over unknown-length collections, state carried across runs, conditional branching four deep. Possible in a builder, painful in a builder.

What a build actually buys you

Error handling you designed rather than inherited. Tests. Logs that answer the question you are actually asking. Behaviour that does not change because a vendor shipped an update on a Tuesday.

And ownership: the thing exists in your repository and keeps working whether or not anyone renews a subscription. That matters more at three years than at three months — the commitments behind it are published, and a build is quoted in two-week increments so you can stop after any one of them.

What a build costs you that nobody quotes

Legibility. A platform workflow can be understood by looking at it; a service cannot. That is a real loss for a small business, and it is the reason a build should come with documentation rather than just a repository.

And it costs you a maintainer. Not much of one — a small integration is not a large ongoing burden — but not zero either. Anyone quoting a build as a one-off with no ongoing line is either absorbing that cost or has not thought about it.

The trade, honestly. This is a framework rather than a benchmark: no vendor figures are asserted, because the numbers that would matter are specific to your volume and your systems.
	Platform	Custom integration
Time to working	Yes Days. Frequently hours for a simple two-system connection.	No Weeks, and it should be quoted in two-week increments so you can stop.
Legible to a non-developer	Yes Someone can open it and see the steps. This is the most underrated advantage.	No Needs documentation to be understandable, which is why handover should itemise it.
Error handling you control	Partly Retries and logs exist, but the behaviour on partial success is the vendor’s design, not yours.	Yes You decide what a failure means and what happens next. This is the main reason to build.
Cost as volume rises	No Rises with successful actions. Fair, and it scales with the thing you wanted cheaper.	Yes Largely flat. Hosting plus maintenance, not per-transaction.
Survives you stopping payment	No Stops when the subscription does.	Yes Keeps running. You own it and hold the code.

The hybrid that usually wins

Keep the platform for the simple, low-volume, visible connections. Build the one workflow that is high-volume or high-consequence. Most of the engagements we run end up here rather than at either extreme.

It is also the cheapest path to finding out. Build the single expensive workflow first, leave the rest on the platform, and you have learned whether a build pays before committing to replacing everything. That is what most of our engagements actually look like.

Two steel toolboxes on a workshop floor: one closed and padlocked, one open with every tray pulled out and the tools visible. — One you can see into. One you own outright. Most businesses want both.

How to tell which side you’re on

Six questions about one specific workflow, not the business in general.

Objections

You build custom integrations — why start us on a platform?

Because a build that was not needed goes badly and we are still here in three years when it does. Starting on a platform also tells us something we cannot learn any other way: whether the workflow is stable enough to be worth hardening.

Isn’t a platform just technical debt?

Only if you never revisit it. A platform workflow that works, is visible and costs forty dollars a month is not debt, it is a sensible answer. It becomes debt when it has grown to thirty steps and nobody will touch it — which is condition one on this page.

Book a free Leak Check

20 minutes. We find where the money's going. No pitch.

Book a free Leak Check