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.
Want to know what this costs in your shop?
I will work out your three biggest time sinks, in hours and dollars. Free, in writing, within 72 hours.
No newsletter, no sequence. You keep the analysis either way.
Tim Muenzel
builds and runs the systems himself
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.
The same decision over three years
Tool comparisons usually stop at the monthly price, which is the one number that flatters the subscription. Over the life of a process that is not going away, the shape matters more than the rate.
| Make | Owned system | |
|---|---|---|
| Year 1 | Subscription plus the build time you still spend | Build cost, once |
| Year 2 | The same subscription again, usually higher | Nothing to rent |
| Year 3 | The same again, plus whatever the plan changed to | Nothing to rent |
| If volume doubles | Operations double, so the bill roughly doubles | The server bill barely moves |
| If the builder leaves | Nobody can safely change the scenarios | Documented code, any engineer |
| If you stop paying | The logic stops existing | It keeps running on your infrastructure |
Below a few thousand operations a month the subscription wins this table outright, and the teardown will say so. The line moves the moment a failed run costs money rather than patience.
Common questions, answered straight
Is Make the same as Integromat?
Yes. Celonis acquired Integromat in October 2020, and in February 2022 the product was rebranded to Make. Existing scenarios carried over. What changed around it is the plan structure and how operations are counted.
At what point does Make become expensive?
Not at a fixed price, but at a fixed shape: when the number of operations scales with your revenue rather than with your usage of the tool. A scenario that runs a few times a day stays cheap forever. One that touches every order turns success into cost.
We inherited scenarios nobody understands. Rebuild or document?
Document first, always. Write down what each scenario is supposed to achieve and what breaks if it stops. That document is the missing piece, and it makes every later decision cheap, including the decision to change nothing.
Do you build in Make?
No. I build custom code and operate it in production. That is exactly why the recommendation on this page is worth reading: if your problem belongs in Make, I have nothing to sell you, and the teardown will say so.
How long does replacing one scenario take?
A fixed first scope is usually in production within two to four weeks. As a reference for the possible pace: a module requested during a client call was live the next day with 54 of 54 tests green.
What does the alternative cost?
Published rather than negotiated: the teardown is free, a systems audit is $490 and is credited toward the build, build sprints start at $6,900 fixed scope, and operator retainers start at $2,900 a month, cancel monthly.
Related reading
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