Make, n8n or custom development: how to choose without getting it wrong
The real question isn't "no-code or custom development?" That's the wrong framing, one that leads to dogmatic answers in both directions. The right question is: how complex is my process, and how long will I need to maintain this automation?
According to Gartner (2024), more than 70% of automations built on no-code platforms require significant human intervention within 18 months of deployment: either because business rules have evolved, volumes have outgrown the tool's capacity, or error handling was never properly addressed. That figure doesn't disqualify no-code. It simply means that the initial choice has consequences 18 months out that are worth thinking through upfront.
What Make and n8n genuinely do well
It would be counterproductive to dismiss Make, n8n or Zapier on principle. These tools have use cases where they're genuinely superior to custom development on at least two dimensions: deployment speed and business team autonomy.
A workflow connecting a Typeform submission to an Airtable row, triggering a Slack notification and creating a Notion task can be live in two hours with Make. The equivalent in Python with a proper infrastructure would take two to three days, including tests and deployment. At that level of complexity, no-code is the right choice. Full stop.
More specifically, Make and n8n excel in four contexts.
Linear workflows with few conditions. One action triggers a predictable sequence of events. If A then B, then C, then D. No complex branching, no deeply nested conditional logic. Visual tools are built for this type of flow.
Integrations between popular tools with native connectors. Stripe, Salesforce, HubSpot, Slack, Google Sheets, Notion, Airtable: both platforms maintain connectors that handle authentication, pagination, and rate limiting out of the box. No need to re-implement any of that.
Moderate volumes. A few thousand operations per month run comfortably within the standard plans of Make or n8n. Below 10,000 monthly operations, the per-operation cost is reasonable and performance is adequate.
Teams that can maintain the workflows themselves. If the Ops Manager who built the workflow is still around in 12 months and still understands their own construction, maintenance is fast. The legibility of a visual workflow has real value for non-technical teams.
The four real limitations on complex Finance processes
This is where reality gets complicated. The limitations of Make and n8n on serious Finance processes aren't theoretical: they're well-documented and consistently reproducible.
Limitation 1: error handling is not a first-class concern
A webhook that fails at 2 AM in Make doesn't trigger any alert by default. The scenario errors out, stops, and waits to be manually restarted. If nobody checks the Make dashboard in the morning, the incident surfaces at end of day, or when the next customer complaint comes in.
For an invoice chasing process, a reconciliation job, or an ARR update, this fragility is unacceptable. Robust error handling in Make requires manually configured exception modules, alert notifications, and retry mechanisms. It's achievable, but it doubles or triples workflow complexity and moves well outside "accessible no-code" territory.
In custom development, error handling is a first-order concern: automatic retry with exponential backoff, dead-letter queues, PagerDuty or equivalent alerting, structured logs. That's not a bonus: it's the baseline.
Limitation 2: complex conditional logic becomes visually unmanageable
Beyond three or four nested conditions, a Make or n8n workflow becomes a visual graph that nobody can debug with confidence. Branches multiply, Router modules chain together, and nobody can guarantee the whole thing behaves correctly across all edge cases.
A concrete example: a travel expense validation process with these rules. Amounts above €500 require manager approval; amounts above €2,000 require dual CFO sign-off; expenses categorised as "international travel" must apply the current-year mileage rate pulled from a reference Google Sheet; employees on probation cannot submit expenses above €200. In Make, that workflow has four main branches and at least eight decision nodes. Changing one rule requires rebuilding a section. Understanding the full state of the logic requires constant zooming in and out.
In Python or TypeScript, that's twenty lines of readable conditional logic, with unit tests for each case.
Limitation 3: heterogeneous data transformations exceed native capabilities
No-code tools excel at moving clean data between well-structured systems. They run into hard limits the moment data transformation is genuinely complex.
Normalising four different bank statement label formats depending on the issuing bank, parsing expense reports arriving as PDFs, Excel files and emails, extracting amounts from scanned supplier invoices, inferring applicable VAT based on supplier country and expense category: these transformations require code. Make can call a JavaScript function inside a "Code" module, and n8n can do the same, but at that point you're writing code without the testing infrastructure and tooling a developer would use to maintain it properly.
Limitation 4: evolving business rules are hard to maintain
In a Finance process, rules change. Approval thresholds are revised, rate schedules are updated, validation perimeters shift during reorganisations. In a Make workflow, changing a business rule typically means modifying the workflow itself: moving a module, reconfiguring a filter, reconnecting branches. Each change is manual and can introduce regressions.
In well-maintained code, a business rule is often a parameter in a configuration file or a value in a database. Changing it doesn't touch the application logic. The result can be tested before deploying.
Objective decision criteria
Five dimensions help structure the choice.
| Dimension | No-code appropriate | Custom development appropriate |
|---|---|---|
| Rule complexity | Linear, fewer than 3 conditions | Conditional, branching, evolving |
| Source heterogeneity | Structured data, standard formats | Mixed formats, complex parsing |
| Criticality | Informational, alerting | Billing, payroll, reconciliation |
| Monthly volume | Fewer than 10,000 operations | More than 10,000 operations |
| Maintenance outlook | Stable team, stable rules | Technical team available, evolving rules |
The further a dimension shifts toward the right column, the more custom development justifies its higher upfront cost.
Three cases where no-code is clearly sufficient
Case 1: CRM to communication tool sync. When a deal moves to Closed Won in HubSpot, automatically create a project in Notion or Asana, send a Slack notification to the account manager, and add the customer to an onboarding Mailchimp sequence. Three actions, one trigger, no complex logic. Make handles this in 90 minutes of configuration.
Case 2: the automated weekly report. Every Monday morning, pull data from Google Analytics, HubSpot and Stripe, consolidate it in a Google Sheet, and email a summary to the leadership team. Volume is low, sources are well-structured, native connectors exist. An n8n workflow does this job for a fraction of the cost of dedicated development.
Case 3: simple event alerting. When a Stripe invoice has been overdue for more than seven days, send a personalised chasing email to the customer and create a CRM task for the account manager. Simple logic, structured data, controlled volume. No-code is the right tool.
Three cases where custom development is necessary
Case 1: automated Salesforce-Stripe-NetSuite reconciliation. Comparing CRM opportunities, billing subscriptions and accounting entries nightly to detect discrepancies, classify them by type and financial impact, and produce an exception report. Data comes from three sources with different schemas, the matching logic is complex, reliability is critical, and classification rules evolve with internal processes. This is custom development territory.
Case 2: expense automation with internal validation rules. Parsing receipts (PDFs, images, emails), extracting amounts, automatic categorisation, applying company-specific validation rules (approval thresholds by seniority level, rate schedules, exceptions), integration into the payroll flow. Every rule is specific, source formats are heterogeneous, and errors have a direct impact on employee pay. A no-code workflow doesn't handle edge cases reliably enough.
Case 3: multi-system order-to-cash integration. Synchronising order data from an ERP in real time, triggering billing in Stripe or Chargebee by applying complex pricing rules (volume pricing, conditional discounts, multi-year contracts with indexation), updating the ERP with payment statuses, and triggering revenue recognition according to IFRS 15 rules. This process sits at the core of the business: reliability is non-negotiable, the logic is proprietary, and rules change regularly.
How to evaluate your own process before choosing
Before building anything, three questions quickly position a process on the no-code / custom axis.
Question 1: can you describe the process in fewer than ten clear, stable rules? If yes, no-code may work. If the honest answer is "it depends on a lot of special cases", custom development is likely more appropriate.
Question 2: what happens if the workflow fails at 3 AM and nobody notices until 9 AM? If the answer is "not much, we'll reprocess manually tomorrow", no-code's fragility is tolerable. If the answer is "we'd have incorrect invoices, desynchronised data, or impacted customers", you need a robust error infrastructure.
Question 3: who will maintain this process in 18 months? If the answer is "the same person who built it, who knows the tool", maintaining a no-code workflow is realistic. If the answer is "a different team, possibly people who weren't involved in the build", clean code with technical documentation is often more maintainable than a complex visual graph.
Total cost of ownership deserves an honest calculation. Make at €300/month looks far cheaper than a €15,000 development project. But if a CFO or Ops Manager spends two hours a month correcting workflow errors, reprocessing edge cases, and explaining how it works to every new hire: over three years, those 24 annual hours represent, at €80/hour fully loaded, €5,760 per year. Before factoring in errors that go unnoticed and their downstream impact on billing or cash flow. The real calculation looks different from the sticker price.
No-code and custom development aren't opposites: they address different levels of complexity. The mistake isn't choosing one or the other: it's choosing for the wrong reasons, without having honestly assessed the real complexity of the process and the long-term cost of maintaining it.
Sources: Gartner "Market Guide for Robotic Process Automation" (2024), Forrester "The Total Economic Impact of Automation Platforms" (2024), Make.com documentation, n8n documentation.