“A client needs a system: when a new deal is created in HubSpot above a certain value, create a proje. Something that used to take 30 minutes took 30 seconds. They looked at the old way and couldn't believe they'd tolerated it. That was the aha.”
When I'm a client needs a system: when a new deal is created in hubspot above a certain v, I want to automate workflows that involve real logic — branches, loops, error handling, so I can build reliable systems that run without requiring manual intervention or repairs.
An operations lead, automation specialist, or technical non-developer who moved to Make (formerly Integromat) after hitting the ceiling on Zapier. They know what they wanted to build and Zapier's linear trigger-action model couldn't do it: conditional branches, iterators, error handlers, multi-route flows. Make could. They learned Make. They have built things in Make that non-technical people would describe as software and technical people would describe as creative. They exist in the middle of the developer-to-non-developer spectrum and they've built a practice there.
To automate workflows that involve real logic — branches, loops, error handling — reliably, without workarounds, and without becoming the team's single point of failure for make.
A operations lead, automation specialist, or technical non-developer who trusts their setup. Automate workflows that involve real logic — branches, loops, error handling is reliable enough that they've stopped checking. Error messages linked to the specific module and the specific field that failed. They've moved from configuring make to using it.
A client needs a system: when a new deal is created in HubSpot above a certain value, create a project in ClickUp with the deal details, send a Slack message to the relevant team, create a folder in Google Drive, and log the action to a Google Sheet for audit. If the deal is below the threshold, only log it. If the HubSpot call fails, retry twice and then send an alert. They're in Make's canvas building this. It's 38 modules. It works. They've tested four edge cases. They'll test two more before marking it ready.
Has 20–80 active scenarios across multiple client or internal automations. Uses Make's advanced features: routers, aggregators, iterators, error handlers. Builds for clients or their own organization — sometimes both. Uses Make's execution history for debugging. Has templates for common patterns they reuse. Connects Make to 15–30 different apps. Has migrated Zaps to Make scenarios at least once. Knows which apps have better Make modules vs. better Zapier integrations. Has considered building a low-code SaaS product on Make infrastructure.
Two things you'd notice: they reference make in conversation without being asked, and they've built workflows on top of it that weren't in the original plan. Automate workflows that involve real logic — branches, loops, error handling is consistent and expanding. They're now focused on build reliable systems that run without requiring manual intervention or repairs — a sign the basics are solved.
It's not one thing — it's the accumulation. Scenario errors that produce cryptic messages not linked to the module that failed that they've reported, worked around, and accepted. Then a competitor demo shows the same workflow without the friction, and the sunk cost argument collapses. Their worldview — every repetitive human task is a bug in a system that hasn't been fixed yet — makes them unwilling to compromise once a better option is visible.
Pairs with `zapier-primary-user` to map the linear-trigger vs. visual-logic automation tool spectrum. Contrast with `retool-primary-user` for internal automation vs. internal tools as different solutions to the same ops problem. Use with `clickup-primary-user` for operations teams where ClickUp tasks and Make automations form the operational backbone.