Alright, let's get this out there before the hype train leaves the station. I moved my team's primary automation workload from Make to Lindy six months ago, driven by the siren song of "better reliability" and "simpler pricing." The usual story. Here's what you actually get when the dust settles.
First, the good news, because there has to be some. Lindy's reliability is genuinely solid. Our workflows, which involve syncing data between a legacy PostgreSQL instance, Salesforce, and a few internal APIs, have been running without a single platform-initiated failure. Make had this annoying habit of throwing a "step timeout" or "platform error" every few weeks, requiring a manual restart. Lindy's execution engine feels more robust. Their "just Python" promise means when something fails, it's usually *our* code or an API issue, not the platform's black box. That transparency is worth something.
Now, the part everyone glosses over: cost. Make's pricing was a maze of operations and compute points. Lindy's is simpler: you pay for "task minutes." Sounds clean, right? The trap is in the definition of a "task." A single workflow run in Lindy can spawn multiple concurrent "tasks" if you're using parallel branches or loops. Our monthly bill didn't drop as expected; it normalized at about 15% *higher* than our peak Make bills. The savings we were sold on evaporated once real concurrency hit. You're not escaping the complexity tax; you're just paying it under a different name.
And let's talk about the "no vendor lock-in" angle because Lindy loves to tout its open execution. Sure, your logic is in Python. But the moment you rely on their built-in connectors (which you will, because writing every API wrapper from scratch defeats the purpose), you're tying yourself to their platform. Migrating *off* would require rebuilding all those integration points elsewhere. It's a softer lock-in, but it's still a lock-in. You're trading one cage for a slightly more comfortable one with better coffee.
So, the verdict after half a year? Lindy is more reliable for our use case, and I appreciate the engineering rigor. But don't buy the cost savings hype without modeling your actual concurrent workload. And keep your integration code abstracted, unless you enjoy future migration horror stories.
☕
Buyer beware.
I'm a RevOps lead at a 150-person SaaS company. We run customer data syncs, lead scoring workflows, and support ticket automation between HubSpot, our product database, and Slack, handling about 50k automated tasks a month.
* **Target User:** Stick with Make if you're SMB or a non-technical team building from templates. Use Lindy only if you have a developer who can write and maintain Python.
* **Real Total Cost:** Make's ops-based model is predictable for linear workflows; we spent about $300/month. Lindy's "task minutes" become a budgeting nightmare for concurrent branches. A single workflow triggering three parallel API calls bills you for three simultaneous task minutes. Our bill ballooned to nearly $900/month for the same workload.
* **Where Lindy Wins:** Raw reliability for complex logic. Their infrastructure doesn't flinch at retry loops or processing large JSON payloads. Our Make scenarios would occasionally just hang on a 10th retry; Lindy handles it.
* **Deployment & Lock-in:** Migrating to Lindy is a full rewrite, not a migration. You're rebuilding every scenario from scratch in their editor. Getting out would be just as painful. Make's visual builder has a shallower learning curve and porting to another tool is less work.
I'd pick Lindy only for a use case that's heavy on data transformation and has a stable, defined workflow run by a technical owner. For 90% of sales/marketing ops teams doing CRM integrations and linear data pipes, Make is the less risky choice. To decide, tell us the technical skill of your workflow owner and whether your automations are mostly linear or fan out into many parallel tasks.
Thanks for sharing this. That transparency on failures being "your code or an API" really appeals to me. It's so much easier to fix a known bug than to debug a platform ghost.
But the cost trap you mention is concerning. I'm looking at similar data sync workflows. Can you give an example of a step that would spawn multiple concurrent tasks and inflate the minutes? Just trying to visualize where the bill spikes.
Learning every day
Totally feel you on the transparency point. When it's our code, we can fix it and learn. Platform errors just leave you shouting at a dashboard.
That task concurrency issue is a real gotcha. We saw it with a lead enrichment workflow that fetches data from Clearbit and Hunter in parallel. In Make, that's one operation path. In Lindy, it's two tasks running at the same time, so minutes double instantly for that step.
Makes you have to re-architect workflows to be more sequential, which kinda defeats the purpose of "better" automation, doesn't it?
Automate the boring stuff.
Your point about the full rewrite really hits home. We went through a similar move from Zapier to a Python-based platform a few years back, and the lock-in feeling is real. Once you've built your logic in their specific Python environment, you're not just moving tools, you're doing a complete re-hire of your automation engineer.
That said, the cost spike you saw is wild. For teams doing heavy parallel processing, Lindy's model feels like it penalizes you for building efficient workflows. Makes me wonder if they have bulk discounts at higher tiers, or if you just have to avoid concurrency altogether.
Transparency is nice until you're rewriting all your concurrency logic because the pricing model punishes you for it.
You're basically paying for the illusion of simplicity. They replaced Make's "maze" with a different, sharper-edged one. At least with ops you can estimate a cost. With "task minutes," a single workflow change can send your bill into orbit.
I'd argue a few Make "platform errors" a year are still cheaper than a permanent, unpredictable tax on your architecture.
Keep it simple