An honest comparison
Custom automation
vs. Make (Integromat)
I use Make where it genuinely fits, and I’ll tell you below exactly where that is. But I also inherited what happens when it doesn’t fit: a client of mine was paying a Make.com contractor €10,000 a month before we replaced the whole setup with a platform they own. That story is the honest center of this page.
The €10,000-a-month Make setup
The client is a German marketing and video-production agency doing about €3M in revenue. Their operations ran on Make scenarios maintained by an external no-code contractor, and keeping that alive cost €10k every month. Not once. Every month, forever, with the logic living in the contractor’s head and the contractor’s account.
Nobody planned that. It started the way it always starts: one scenario that worked, so they added another. The tool wasn’t the problem; the accumulation was. Per-operation pricing meant the bill grew with their success, and key-person risk meant no change could ship without the one person who understood the tangle.
We replaced it with a custom platform in their repo, on their database, tested and monitored: 229 API routes, 25 background jobs, operated daily. The recurring €10k/month became a one-time investment in an asset they keep if I disappear tomorrow.
When Make is genuinely the right call
I want to be fair here, because I built plenty on this tier myself before moving to custom code, and I still recommend it when it fits. Make is the right tool when the workflow is a straight line between two or three apps, the volume is low, and a silent failure for a day would annoy you rather than cost you revenue. “New form entry, add a row, send a Slack message” does not need an engineer. If that describes your operation, keep Make and spend your money elsewhere.
When it quietly becomes a liability
Three failure modes show up again and again, and they compound each other. Scenario sprawl: logic that should be one tested codebase gets smeared across dozens of scenarios nobody can see whole. Per-operation pricing: the more your business processes, the more you pay, so the tool taxes exactly the growth it was supposed to enable. Key-person risk: the contractor who built it becomes a single point of failure you pay monthly to not lose. My client had all three at once. The invoice just made it visible.
The comparison, straight
| Make | Custom system | |
|---|---|---|
| Best for | Linear scenarios between two or three apps | Operations your business depends on |
| Monthly cost | Per-operation pricing that scales with your volume | $0 to exist; you own the code |
| Who understands it | The person who built the scenarios | Documented code in your repo; any engineer |
| Testing | Run the scenario and watch what happens | Automated test suites, staged rollouts |
| Complex logic | Routers and filters sprawl into spaghetti | Native: queues, retries, state, migrations |
| Data volume | Every row you touch is an operation on the bill | Postgres does millions of rows happily |
| Failure behavior | Incomplete executions pile up quietly | Monitoring, alerting, error budgets |
| Ownership | Rented: cancel the sub, lose the logic | Yours: repo, database, infra, forever |
The rule of thumb I give founders
Keep Make when the workflow is linear, low-volume, non-critical, and any competent person on your team could rebuild it in an afternoon. Go custom when the process touches revenue, the operations bill has become a line item you notice, or one person leaving would take the logic with them. And if the monthly cost of keeping your scenarios alive is approaching the one-time cost of owning the system, the math has already decided for you.
Not sure which side of the line you’re on?
Free systems teardown: your 3 biggest automation leaks, what each costs monthly, and an honest tool recommendation for each. If Make is the right answer for you, the teardown will say “keep Make.” In your inbox within 72 hours.
Get your free systems teardown