Kommo + Make: When No-Code Is Enough, When You Need Development
Make (formerly Integromat) covers most Kommo automation scenarios: create a deal from a form, send a notification, push data into Google Sheets. Custom development becomes necessary when three factors appear - high operation volume, complex stateful logic, and reliability requirements (retries, idempotency, two-way synchronization). If you have dozens of scenarios and hundreds of thousands of events per month, you pay Make more than your own integration would cost, and on top of that you don’t control how it behaves during failures.
In Kommo integration projects we see a recurring pattern: a team starts with one or two scenarios in Make, everything works, a year later there are forty of them, and operation-based billing has turned into a permanent line item. In parallel, the first scenario appears that Make technically can’t handle - for example, two-way synchronization of a deal with an external system without duplicates. According to Make pricing reviews by Zapier, the billing model is built on operations (as of 2025 - on credits), where each module action consumes a credit. This article is about where the line lies between “Make is enough” and “you need development,” with concrete numbers and technical criteria.
The pain isn’t that Make is bad. The pain is that the “no-code or code” decision gets made out of habit rather than calculation. The head of sales sees a scenario working and doesn’t count the cost of operations at scale. The developer sees a Make limitation and wants to rewrite everything, even though Make handles 80% of scenarios perfectly. The right answer is almost always hybrid - and to find it, you need to understand what Make actually has under the hood.
Make (Integromat): a visual no-code automation platform where a workflow is built from scenarios, and each scenario is built from modules that perform actions with apps. Billing is based on operations/credits charged for each module execution.
What Make Solves Well for Kommo
Make covers the entire class of linear, event-driven Kommo automations without a single line of code. That is its strength, and for most teams it is enough.
Make has a ready-made Kommo app with modules for the main entities: create and update a deal, contact, company, add a task, attach a note. Triggers catch events via a webhook on the Kommo side. Where this is a perfect fit:
- Linear “event -> action” scenarios. A request comes in from Typeform -> create a deal in Kommo. A deal moves to a stage -> send a message to Slack. One input, predictable output.
- Low and medium volume. Hundreds, at most the first few thousand executions per month. At this volume operations cost pennies.
- Pushing data into simple destinations. Google Sheets, Notion, an email blast, a notification. Where you don’t need delivery guarantees and complex response handling.
- Quick prototypes. Test an automation hypothesis in an hour, without a developer and without a release.
If you’re only just setting up processes in Kommo, start with Make. The logic of setting up a pipeline in Kommo and basic automations map perfectly onto the visual builder. Moving to code only makes sense when you hit a specific ceiling - not before.
Where Make Hits Its Ceiling
Make stops being cost-effective and reliable on four types of tasks: volume, state, reliability, and two-way synchronization. Let’s break down each one.
Operations Billing at Scale
The main hidden multiplier is the charge for each module action. The first module of a scenario consumes one credit. Each subsequent module consumes a credit for every processed bundle (data package). Routers, filters, and iterators also spend operations - even when the condition isn’t met.
This means: a 6-module scenario triggered on a single deal is 6 operations, not one. If you have 50,000 deals per month and a 6-step scenario, you pay for 300,000 operations. According to the pricing breakdown by Zapier, at such volumes a Make subscription turns into thousands of dollars per year. The same logic implemented as your own service on a Kommo webhook costs a fixed amount - the price of hosting, not the price per operation.
Complex Logic and State
Make thinks in scenarios without long-term memory. Each run is an isolated pass through modules. As soon as the logic requires storing state between runs (accumulating events, waiting for N actions, deduplicating by history) - you start building workarounds: writes to Google Sheets as a “database,” a Data Store with limitations, chains of scenarios triggering each other. This works as long as the logic can be drawn out. When you have a conditional graph with a dozen branches and a dependency on past data, the visual scenario becomes unreadable and fragile.
Error Handling and Retries
Make has error routes and directives (Resume, Rollback, Commit, Break), as well as delay modules for retries. For a simple “retry on 429 or 500” this is enough. But, as noted in breakdowns of error handling in Make, for a production load with a circuit breaker, a dead-letter queue, and fine-tuned backoff per endpoint, you need code. In Make, every retry is operations again, and the error handling itself has to be duplicated manually in each scenario. Across forty scenarios this becomes a separate maintenance problem.
Two-Way Synchronization and Idempotency
The most common case where Make breaks is two-way sync. Kommo and the external system must reflect each other’s changes, and you can’t allow duplicates or infinite echo (a change in A triggers an update in B, which triggers an update in A). Make provides no built-in idempotency mechanism.
Idempotency: the property of an operation to produce the same result when executed repeatedly - calling “create a deal” again must not spawn a second duplicate.
To make sync safe in Make, you have to manually build external-ID fields, upsert logic, and dedup checks before each creation. This is possible, but it turns “no-code” into hidden development inside the visual editor - without tests, versioning, or control. In your own service, idempotency is solved with a key and a check in the database in a couple of hours of work.
What “You Need Custom Development” Actually Means
Custom development becomes necessary when you cross at least one of the four boundaries - and that boundary is persistent, not a one-off. A one-off complex scenario can be tolerated in Make. A systemic load cannot.
Checklist for crossing the line:
- Volume. Consistently above ~10,000 operations per month in one direction, and the Make bill grows faster than your own hosted service would cost.
- State. The logic requires storing and analyzing the history of events, not reacting to one event at a time.
- Reliability. A lost or duplicated record costs money - a payment, an invoice, inventory synchronization. You need delivery guarantees, idempotency, proper retries.
- Two-way flow. Data must flow in both directions without echo and duplicates.
- Coupling. There are so many scenarios that you no longer remember which does what, and any API change breaks half of them.
If two or more points match - calculate the TCO of your own integration. Usually it pays off within a few months. More on the approach - on the page about custom integrations for Kommo.
Comparison: Make vs. Custom Development
Short verdict: Make wins on launch speed and low volume, custom wins on cost at scale, control, and reliability. A table along the key axes.
| Criterion | Make (Integromat) | Custom Development |
|---|---|---|
| Cost at scale | Grows linearly with the number of operations | Fixed (hosting), independent of volume |
| Launch speed | Hours, no developer | Days to weeks, developer required |
| Control over logic | Limited by platform modules | Full, any logic and state |
| Flexibility (retries, idempotency) | Basic, manual workarounds | Full, at the code level |
| Two-way sync | Fragile, no guarantees | Reliable, with deduplication |
| Support and debugging | Visual logs, but duplicated logic | Logs, tests, versioning |
| Vendor dependency | High (prices, limits, changes) | Low, the code is yours |
Important: this is not an either/or. Often the optimal choice is to keep simple scenarios in Make and move the volume- and reliability-critical ones into your own service. A hybrid saves both time and money.
A Real Case with Numbers
In a typical project, a team on Kommo came to us with this picture: 38 scenarios in Make, around 280,000 operations per month, billing of about $200 per month and growing. The main pain wasn’t the price - it was a single scenario for two-way synchronization of deals with an external billing system, which created duplicates once a week and required manual cleanup.
What we did. We left 31 simple scenarios in Make - they’re cheap and stable. We moved seven heavy scenarios (two-way sync, deduplication, event aggregation) into a single service on a Kommo webhook with idempotency by external-ID and proper retries with exponential backoff. The result in the first month: operations in Make dropped by roughly 60%, duplicates in synchronization fell to zero, and manual data cleanup stopped eating up the manager’s time. Their own hosted service costs a fixed ~$25 per month instead of a growing operations bill.
The main takeaway of the case: rewriting everything was unnecessary. It was enough to move the seven scenarios that accounted for 60% of operations and 100% of the reliability problems.
What’s Right for Whom
Make is enough if you’re a team of 15+ people, you have tens of thousands of events per month or fewer, your scenarios are linear, and the cost of a data error is low. This is most teams at the start and in the middle of the journey. If you’re still figuring out what the platform can do, start with the Kommo CRM overview and build your first automations in Make.
Custom development becomes necessary if you’ve crossed two or more boundaries from the checklist: high volume, state, reliability requirements, two-way sync. This is usually mature teams whose revenue depends on data correctness in the CRM - payments, invoices, ERP synchronization. Most often the right solution is a hybrid: Make for the simple stuff, your own service for the critical stuff. The Exceltic.dev team can help design the architecture and estimate the scope of work.
Frequently Asked Questions
When is Make cheaper than custom development for Kommo?
Make is cheaper as long as the operation volume is low and the scenarios are simple. The benchmark is up to a few thousand operations per month. At this level you pay tens of dollars for a subscription, and developing your own service won’t pay off. As soon as the volume consistently exceeds ~10,000 operations per month in one direction, or a scenario with many modules triggers on every deal, operation-based billing starts to overtake the fixed cost of your own hosted service. At that point it’s worth calculating the TCO: the price of Make for a year versus one-time development plus hosting.
Can you build reliable two-way synchronization in Make?
Technically yes, but at that point it’s no longer no-code - it’s hidden development inside the visual editor. Make provides no built-in idempotency or echo protection (when a change in system A triggers an update in B, which triggers back to A). To make sync safe, you have to manually add external-ID fields, upsert logic, and dedup checks before each record creation. This works, but without tests, versioning, or version control - and every API change in one of the systems risks breaking everything. Reliable two-way sync is almost always cheaper and more stable to build in code.
What are operations in Make and why are there so many?
An operation (as of 2025 - a credit) is charged for each module execution. The first module of a scenario is one operation. Each subsequent module consumes an operation for every processed data package (bundle). Routers and filters also spend operations, even if the condition didn’t match. That’s why a 6-module scenario is 6 operations per trigger, not one. At a volume of tens of thousands of deals this turns into hundreds of thousands of operations per month. It’s precisely this non-obvious multiplication of operations by the number of modules that makes Make expensive at scale.
Do you need to rewrite all Make scenarios when moving to custom?
No, and this is a common mistake. In most projects Make handles 80% of scenarios perfectly and cheaply - those don’t need to be touched. The only ones worth rewriting are those responsible for the bulk of operations or for critical reliability: two-way sync, deduplication, stateful aggregation, payment processing. Usually that’s 10-20% of scenarios, which account for 60-80% of operations and almost all the problems. A hybrid architecture - Make for the simple stuff, your own service for the heavy stuff - saves both the development budget and the cost of operations.
Make or your own integration via the Kommo API - what to choose to start?
For a start it’s almost always Make. It lets you test an automation hypothesis in an hour, without a developer and without a release. You’ll quickly understand which scenarios you actually need and how heavily loaded they are. Your own integration via the Kommo API is justified once you already know the volume and reliability requirements - that is, after Make has shown its limits on your specific case. Premature development is just as much a mistake as stubbornly sticking with Make at a volume where it has become expensive.
Bottom Line
- Start with Make. For linear scenarios and low volume it’s faster and cheaper than any development. Don’t write code in advance.
- Count operations at scale. A scenario of N modules costs N operations per trigger. At tens of thousands of deals, the billing overtakes the cost of your own service.
- Move only the critical stuff into code. Two-way sync, idempotency, state, payment reliability - these are the boundaries beyond which Make becomes fragile and expensive.
- A hybrid is the norm, not a compromise. Make for the simple stuff, your own service for the heavy stuff. You don’t need to rewrite everything.
If you’ve hit the Make ceiling - a growing operations bill, duplicates in synchronization, or a scenario you can’t draw out - describe the task to the Exceltic.dev team. We’ll review the architecture, calculate what to keep in Make and what to move into code, and estimate the scope of work.