The Wiring Between Everything

I've linked to this tool in almost every article I've written this year, which means I owe you an honest review of it rather than another passing mention.

Make is the automation layer I actually run. It's the thing sitting between your CRM and your inbox and your spreadsheet and your calendar, moving information around so a human doesn't have to. If you've read anything here about follow up sequences or client reporting or content pipelines, Make was the assumed plumbing underneath it.

So let's do this properly. What it genuinely does well, where it will hurt you, what it costs once you're past the trial, and the specific kind of business that should not touch it.

Make is a visual automation platform. You build workflows by dragging modules onto a canvas and connecting them with lines. Each module is one step, usually one action in one app. Watch for new rows in a sheet. Find a matching record in a CRM. Send an email. Post to a channel. Wait. Branch based on a condition.

The mental model is a flowchart that runs. That sounds obvious until you compare it to the alternative, which is either writing code or using something that hides the logic from you behind a wizard. Make shows you the whole thing at once, which turns out to matter enormously when something breaks at eleven at night.

It connects to somewhere north of two thousand services out of the box, and where a connector doesn't exist there's a generic HTTP module that will talk to anything with an API. That last point is the difference between a tool you outgrow in a year and one you don't. Every automation platform is fine until you hit the thing it doesn't support, and what happens at that moment determines whether the platform was a foundation or a phase.

The canvas is not a gimmick. I resisted this for a while because visual programming has a long history of being a nice demo and a terrible working environment. Make is the exception, and the reason is that the visual layout maps to how automations actually fail. When a workflow breaks, it breaks at a specific step, and being able to see that step highlighted in the context of everything around it collapses the debugging time dramatically. I've had automations break at inconvenient hours and diagnosed them from a phone, which I could not do with a text based system.

The error handling is genuinely serious. This is the unglamorous feature that separates automation you can rely on from automation you have to babysit. Make lets you attach error handlers to individual modules, define retry behavior, and route failures somewhere useful instead of just stopping. That means an API that's briefly down at two in the morning doesn't silently kill your Monday reporting. It retries, and if it still fails, it tells you. Most competing tools treat errors as an afterthought and you find out three weeks later that nothing has run since the eleventh.

The data handling is a real step up. Make can hold arrays, iterate over them, aggregate results, and pass structured data between steps without you flattening everything into text. This sounds like a technical detail and it's actually the ceiling on what you can build. The moment your automation needs to process a list of things rather than one thing, simpler tools force awkward workarounds and Make just does it. Anything involving multiple line items, multiple recipients, or multiple records in one run lives here.

Now the part reviews usually skip.

The learning curve is real and it is front loaded. Your first automation will take you three hours and it should take twenty minutes. The concepts are not hard but there are enough of them that the first build is mostly confusion. Mapping data between modules, understanding when a bundle is one item versus many, working out why your filter isn't matching. Everybody hits the same wall in the first week and a meaningful number of people quit at it.

If you push through, the second automation takes forty minutes and the fifth takes ten. But I'm not going to pretend the first week is pleasant, and if you're evaluating this on a Saturday afternoon with limited patience, you'll conclude it's too complicated. It isn't. It's just poorly front loaded.

The pricing model will surprise you at least once. Make charges by operations, and an operation is roughly one module doing one thing one time. This is fair and it's also completely disconnected from how you think about your own work.

Here's how it goes wrong. You build something that checks a spreadsheet every fifteen minutes. Feels cheap. It's ninety six runs a day, times however many modules are in the scenario, times thirty days. A five module scenario polling every fifteen minutes is roughly fourteen thousand operations a month by itself, and you built it in ten minutes without thinking about it.

The fix is easy once you know: use webhooks instead of polling wherever the source supports it, so the scenario runs when something happens rather than constantly asking whether something happened. Put your filters as early in the scenario as possible so you're not running eight modules on records you're going to discard. Increase your polling intervals on anything that isn't genuinely urgent. Almost nothing is genuinely urgent.

But you will get this wrong once, and you'll find out via an email telling you you're near your limit. Budget for that.

Some connectors are noticeably better than others. The major ones are solid. The long tail varies. You'll occasionally find a connector that supports eighty percent of what the underlying service does and the missing twenty percent is exactly what you needed. The HTTP module is the escape hatch and it works, but using it means reading API documentation, which is a different activity than dragging boxes and not everyone wants to do it.

It is not a CRM and people keep trying to make it one. Make moves data. It doesn't store it in any way you'd want to build on. Every few months I see someone who has constructed something elaborate where Make is effectively the system of record, and it's always fragile and always eventually collapses. If you need things stored and queried, put a real database or a real CRM underneath and let Make be the connective tissue.

Want the builds rather than the blank canvas?

The AI Workflow Blueprint includes the specific scenarios I'd build first, the follow up detector, the client reporting pipeline, and the content distribution chain, with the operation counts worked out so you don't discover the pricing model the hard way. Forty seven dollars. Reply with BLUEPRINT and it's yours.

There's a free tier with a thousand operations a month and it's a real tier, not a demo. You can build genuine things on it. For a solo operator with two or three modest automations it may be all you ever need.

Paid plans start around nine or ten dollars a month at the entry level and scale with operation volume. For most small businesses running a handful of real automations you're landing somewhere in the ten to thirty dollar range monthly, which against the labor it displaces is not a close call. If one automation saves you two hours a month you're up on the deal several times over.

Where it gets expensive is high volume work, particularly anything processing large record sets frequently. If you're moving thousands of records daily, do the operation math before you commit, because that's the scenario where a custom script starts looking economically reasonable.

Check current pricing before you plan around any of this. Every tool in this category has been repricing this year and the pattern across the industry has been a steady march toward usage based billing. Assume the number moves.

If you do start, don't begin with the impressive one. Begin with these, in this order, because they teach you the concepts in the sequence that makes them stick.

Build one: a notification with context. Something happens in one system and you want to know about it somewhere else, with the useful details attached. A form submission that posts to your team channel including the answers, not just an alert that a form was submitted. This teaches you triggers, data mapping, and formatting, and it's forgiving because nothing breaks if it fails.

Build two: a scheduled assembly. Every Friday, pull records from one place, filter them, format them, and deliver a summary. This is where you learn filters, aggregation, and the operations math, because this is the scenario type that quietly eats your quota if you're careless. Build it, then look at how many operations one run consumed, then optimize it. That exercise is worth more than any tutorial.

Build three: something with a branch and an error handler. A condition where one thing happens if a record looks one way and something else happens if it doesn't, plus a route for when the whole thing fails. This is the one that turns a toy into infrastructure. Once you've built a scenario that handles its own failures gracefully, you'll stop thinking of automation as fragile, because yours won't be.

Three builds, maybe five hours total across a couple of weeks. At the end of it you'll know whether this is a tool you want to live with, and you'll know it from experience rather than from a review, including this one.

Skip Make if you have exactly one automation you need and it's simple. If all you want is form submissions landing in a spreadsheet, use something simpler or the native integration. Make's advantages compound with complexity and are invisible at low complexity.

Skip it if nobody in your business will own it. This is the one that actually matters. Automations need maintenance. APIs change, credentials expire, a service updates its schema. If the answer to "who fixes it when it breaks" is nobody, you're building a thing that will fail quietly and you won't notice until something downstream is badly wrong. Either somebody owns it or you pay somebody to own it. There is no third option and pretending otherwise is how people end up distrusting automation generally.

Skip it if you're already deep inside an all in one platform that does what you need. If you run Go High Level and your automations live entirely within your pipeline and messaging, adding another layer buys you complexity you don't need yet. Add Make when you need to reach outside that box, not before.

Make is the automation tool I'd pick again, and I'd pick it specifically because of how it behaves when things go wrong rather than how it behaves in a demo.

That's an unromantic reason to choose software and it's the correct one. Automation isn't hard to set up. It's hard to keep running. The tools that fail small businesses fail six weeks in, silently, and the failure gets discovered when a client asks why they didn't get their report. Make's error handling, its visual debugging, and its escape hatch for services it doesn't natively support are all features that only pay off after the honeymoon, which is exactly when you need them.

The learning curve is real, the pricing model requires one lesson you'd rather learn from this article than from a bill, and it wants an owner. Given all three, it's still the one.

Start on the free tier. Build the ugliest, most annoying manual process you have, the one you do every week that you resent. Don't try to build the elegant version. Build the version that works, watch it run for two weeks, and then decide whether you want the next one.

Ready to stop assembling tools and start running a system?

A single automation saves hours. A connected set of them changes what your week looks like. Inside the AI Business Accelerator we build the whole stack together, the intake, the follow up, the delivery, the reporting, wired so the pieces feed each other instead of sitting in separate tabs. Ninety seven dollars. Reply with ACCELERATOR and we'll build it.

Jordan

The AI Newsroom | Jordan Hale | ainewsroomdaily.com