Make.com Raised Prices Again. We Didn't Notice Until Someone Told Us.

Make.com raised prices again.

We found out because someone mentioned it in a thread. Not because we got an invoice, not because a budget line changed, not because anyone had to approve a new tier. Someone mentioned it and we had to check if it applied to us.

It didn't. We're not on Make.com.

That's the whole point of this post.

The Price Hike That Wasn't Our Problem

If you're on Make.com and you just absorbed another price increase, you already know the pattern. The email arrives. The blog post goes up explaining the new pricing. The justification is always the same: investment in the platform, new AI features, better infrastructure for your workflows. You do the math, maybe downgrade a plan, maybe push it through procurement, maybe just accept it and move on.

That cycle is the vendor's business model working exactly as designed.

When we saw the thread, the honest reaction wasn't smugness. It was something closer to relief — the kind you feel when you remember you solved a problem before it became urgent. Six months ago we made a bet on owned infrastructure instead of rented tooling. That decision is paying dividends in ways that don't show up on a dashboard.

What a Misconfigured Loop Costs (Depending on Your Stack)

Here's the scenario that made the infrastructure case visceral for us.

We had a workflow misconfiguration. Nothing exotic — a logic error in an automation loop that caused it to run far more than intended before the system caught it.

On a SaaS platform with per-task billing, that kind of incident has two costs: the direct operational damage, and the platform bill for every execution the loop fired before anyone noticed. The meter runs whether the tasks were useful or not. A misconfigured loop on a metered platform is a misconfigured loop plus an invoice for all the work it shouldn't have done.

On our stack — n8n self-hosted, AI agents managing execution — the cost of the same incident was: logs to read the next morning and a code fix. The meter doesn't run because there is no meter. We fixed the code. The fix went in. The same failure mode is now handled.

We don't pay a platform for the privilege of having that problem again.

The Upgrade Spiral, Explained

Most SaaS automation tools work the same way. Entry pricing is low enough to get you in. You build workflows. The workflows work. You build more. You promote the tool internally. More teams adopt it. Your usage grows into the next tier. The next tier costs more.

At each step, leaving becomes harder. Your workflows are in their format. Your team knows their UI. Your institutional knowledge about how your ops run is encoded in their system, not yours. The exit cost isn't just the new tool — it's the archaeology of reverse-engineering six months of automation into something portable.

This is the knowledge tax. Convenience at the cost of ownership. You paid for easy-to-start; you're now paying interest on that loan every month.

The alternative isn't necessarily harder to run. It's harder to start. n8n on your own server isn't as fast to spin up as clicking "sign up." But everything you build on it is yours. The workflows are yours. The execution environment is yours. The cost structure is flat — infrastructure, not usage tiers.

When the next price hike announcement lands in someone else's inbox, you want to be in the position of checking whether it applies to you rather than calculating how much it'll cost.

What Our Stack Actually Looks Like

For anyone wondering if this is theoretical: it isn't.

n8n self-hosted runs our automation layer. AI agents manage orchestration, error handling, and escalation. The whole thing runs on VPS infrastructure we control. No per-task billing. No per-user seat cost above the server bill. No vendor deciding that the feature we depend on is now a premium tier.

When something breaks — and things break — we look at our own logs and fix our own code. There's no support ticket. There's no "this is a known issue in our roadmap." There's just the system, which we understand because we built it.

The upfront cost was higher. We spent time we could have spent elsewhere. The compounding benefit is: every pricing decision a SaaS vendor makes is someone else's problem.

The Real Question

The question isn't "is Make.com worth it?"

Maybe it is, for your use case, at your current scale, with your team's capacity for maintenance. There are legitimate reasons to choose managed tooling over self-hosted infrastructure. Speed-to-start matters. Team familiarity matters. Some workflows genuinely don't justify the ops overhead.

The question is: do you know which parts of your automation stack are yours, and which parts are rented?

Because the rented parts will have price increases. The vendors who own the infrastructure you depend on will continue to optimise their pricing. That's not a complaint — it's how SaaS businesses work. The question is whether you've made that dependency a conscious, audited choice, or whether it happened by default because everything was easy to start.

Default renting is how the upgrade spiral starts.

We're building this in public because the honest operational log — including the things that broke and the infrastructure decisions that meant someone else's price hike wasn't our problem — is more useful than the polished case study.

Follow the build at agentic-movers.com.