Skip to content
Make · Integromat-era experience · Modern automation

Make automation — built on years of it, honest about what’s next

We’ve been building automations on Make since it was Integromat — invoicing pipelines into Xero, marketplace-to-API middleware, the bookkeeping and ops glue that quietly runs a business. We know where Make is the fastest way to ship a working automation, and we know exactly where it stops scaling. These days we more often reach for Python, FastAPI, and AI/MCP tooling — but when Make is the right call, we build it cleanly, and when it isn’t, we’ll tell you.

Make
Integromat-era experienceXero + bookkeeping flowsAPI middlewareModern-stack migration path

Why teams bring us their Make work

Long tenure with the tool, real revenue-touching work, and an honest read on where it stops.

Since Integromat

We didn’t arrive at Make in the no-code boom. We’ve been wiring scenarios since the Integromat days — long enough to know its real limits, not just its happy path.

Real money flows

Our Make work runs invoicing and bookkeeping into Xero and bridges marketplaces to external booking APIs — automations that touch revenue, not toy demos.

Honest about the ceiling

Make is an older-school automation framework. For anything heavy, high-volume, or logic-rich we build it in Python / FastAPI with AI/MCP tooling — and we’ll say so before you overspend on scenarios you’ll outgrow.

When Make genuinely earns its place

Make still earns its place in a specific lane: when you need a working automation this week, without a custom-code budget, connecting tools that already have solid APIs.

Speed to working

A visual scenario that moves data between known tools beats a from-scratch build when the logic is linear and the volume is modest.

Hundreds of connectors

When the integration you need already exists, you’re wiring, not coding.

Cheap to prove a workflow

Validate that an automation is worth having before investing in a hardened custom version.

A real migration on-ramp

We’ve used Make as the first version of a process, then rebuilt the parts that mattered in Python once the workflow proved itself.

When we reach for Make — and when we don’t

We reach for Make when
  • The workflow is linear and the volume is modest.
  • Every system involved already has a clean API or a Make connector.
  • You need it shipped fast and cheap, and “good enough and running” beats “perfect.”
  • It’s a first version — prove the process, then decide what deserves a real build.
We move off Make when
  • The logic gets branchy, stateful, or genuinely complex.
  • Volume or reliability requirements grow — scenario costs and fragility climb fast.
  • You need real testing, version control, and observability around the automation.
  • The honest answer is custom code — we rebuild it in Python / FastAPI with AI/MCP tooling.

Make is excellent at being the fast, pragmatic option. We treat it as exactly that — and we tell you the moment a workflow has outgrown it, rather than charging you to keep extending scenarios that should be code.

What we’ve built with Make

Two shipped products where Make runs real, revenue-touching automation.

Integrations we’ve actually wired

We’ve connected Make to the tools real businesses run on.

CRM & sales
HubSpotGoHighLevel (GHL)
Email & comms
GmailPostmarkSlack
Finance & ops
XeroAirtable
Data & apps
BubbleSupabaseXano
APIs & scraping
PostmanApify

And beyond Make: when a workflow outgrows visual scenarios, we rebuild it with Python, FastAPI, and AI/MCP tooling — and we work across the wider automation landscape (n8n, Zapier) so the recommendation is tool-agnostic, not Make-for-its-own-sake.

The modern path

Make got a lot of businesses automated, and it still does. But the way we build automation now has changed: AI agents and MCP tooling let us wire systems together with real code that’s testable, version-controlled, and doesn’t fall over at scale — often for less long-term cost than a sprawl of scenarios. If you’re choosing how to automate something today, we’ll help you pick the honest answer: a clean Make build when that’s genuinely right, or a modern Python + AI/MCP system when you’re building something meant to last.

Related

Make / Integromat — FAQ

Do you build automations on Make / Integromat?

Yes. We’ve built on the platform since its Integromat days — invoicing into Xero, bookkeeping flows, and API middleware between marketplaces and external providers. We build Make cleanly when it’s the right tool for the job.

Should I use Make, or build a custom automation?

It depends on the workflow. For a linear, modest-volume process between tools that already have APIs, Make ships fast and cheap. For anything branchy, high-volume, or logic-heavy, custom code (Python/FastAPI with AI/MCP tooling) is cheaper to run and won’t hit a ceiling. We’ll tell you which fits before you commit.

What can you connect Make to?

In our work: HubSpot, GoHighLevel, Gmail, Postmark, Slack, Xero, Airtable, Bubble, Supabase, Xano, Postman, Apify, and more. If a system has an API, it can usually be wired in.

Can you migrate an existing Make/Integromat setup to something more robust?

Yes — that’s one of the most common things we do. We’ll keep what’s working, rebuild the parts that have outgrown scenarios in Python/FastAPI, and add the testing and observability that visual automations lack.

Make vs Zapier vs n8n — which is better?

There’s no universal winner; it depends on your tools, volume, and how much logic lives in the automation. We’ve worked across all three and, more often now, build the durable version in code. We’ll recommend based on your case, not a tool we’re trying to sell.

Is Make still worth using?

For the right job, yes — fast, cheap, well-connected. For serious, long-lived systems we increasingly build with a modern Python + AI/MCP stack instead. The honest answer is “it depends on what you’re building,” and we’ll help you make that call.