What we build in Make.com

What it is, and where it sits

Make is a visual workflow platform. You build scenarios on a canvas: a trigger module, then modules that fetch, filter, transform and write. It sits between your systems and moves work between them.

It is the tool we reach for first for a typical SMB build, because it hits the balance most businesses need — enough power for real logic, enough legibility that your operations manager can open a scenario and understand what it does.

What we build in it

• Lead capture, routing and CRM sync — the most common Make build we ship
• Client onboarding sequences spanning five or six systems from one trigger
• Order-to-invoice flows between operational systems and Xero or QuickBooks
• Document generation and e-signature routing
• Scheduled reporting assembled from multiple sources
• Approval chains with timers, escalation and audit trail

How it is priced

Priced per operation. One operation is roughly one module doing one thing once, so an eight-step scenario running 500 times a month consumes about 4,000 operations. Your bill scales directly with how much work the automation does.

Estimate your monthly operations before committing: steps per scenario × runs per month, summed across scenarios. High-frequency, low-complexity workflows dominate this number — an email triage flow running 2,000 times a month costs more than an impressive 20-step reporting flow running weekly.

Under roughly 10,000 operations a month the cost is small enough not to be a decision factor. Above roughly 100,000, model it against self-hosted n8n properly.

When it is the right choice

• Nobody on your side wants to run infrastructure — the single biggest factor, and a legitimate reason on its own
• You need broad connector coverage without writing custom HTTP calls
• Non-technical people need to read and eventually modify the workflows
• Volume is moderate and reasonably predictable
• You want mature error-handling routes and rollback behaviour without building them

Limits worth knowing before you commit

• Cost at high volume. Per-operation pricing is unforgiving once you are running hundreds of thousands of operations a month.
• Version control is weak. Scenario history exists but it is not Git. For teams with engineering discipline this is a real drawback.
• Complex logic gets visually unwieldy. Past about thirty modules with several branches, the canvas becomes hard to reason about.
• Heavy data processing is the wrong fit. Transforming 50,000 rows is a job for a script, not a visual platform.