Choose n8n or custom code by examining the work someone must recover when an automation stops halfway through. n8n can make integrations and execution paths easier to inspect. Custom code can give a team a clearer home for complex rules and focused verification. A hybrid can keep those benefits together, provided its interfaces and responsibilities are explicit.
This comparison follows a fictional supplier-onboarding process: receive documents, review a bank-detail change, create a supplier record and notify the requester. It is a planning exercise for operations and product teams, not a benchmark or a claim that MUBBITS has measured savings from this workflow. The decision is relevant across the USA, UK, Canada and Australia; your actual data and operating requirements determine the deployment.
Key takeaways
- Separate routine integration steps from decisions that require durable business state.
- Compare recovery, review and ownership as well as initial build effort.
- An execution marked successful still needs an independently checked business outcome.
- Extract a difficult step before committing to a complete automation rewrite.
Write the process as decisions and outcomes
For supplier onboarding, a form submission is the trigger and an approved supplier record is the useful outcome. Between them sit several different kinds of work: file checks, identity matching, an approval, a database change and a notification. A diagram that connects the apps does not yet explain which decisions govern those changes.
Start with a process sheet. State the required input, the record to update, who may approve it, what happens when an input is missing and how the requester learns the result. Keep a bank-detail change pending until the designated reviewer approves it. A model-generated summary may help the reviewer understand the documents; it should not become the authorization to change payment details.
Then mark which steps can be safely repeated. Looking up a supplier is different from creating another supplier. Re-sending an internal status notice is different from sending a second external confirmation. This distinction makes the platform discussion concrete.
Compare n8n, custom code and a hybrid against this process
Use n8n when the visible sequence and existing integrations help the people who operate the process. Use custom code when a component needs a carefully modeled state transition, reusable business rules or verification that your team can maintain more comfortably in a repository. Either approach still needs appropriate credentials and explicit failure handling.
For this fictional onboarding, one workable hybrid keeps document intake and notifications in n8n, while a small service owns approval state and supplier creation. The workflow passes an onboarding identifier to that service and receives a meaningful result: pending review, approved, rejected or already completed. Operators can follow one request across both systems.
This is one possible design. If an existing procurement system already supplies approval, deduplication and an adequate integration, connecting to that system may be the smaller project. Do not build a second authority for the same supplier just to make the architecture look more sophisticated.
| Requirement | n8n-oriented approach | Custom or hybrid approach |
|---|---|---|
| An operator adjusts a notification sequence | A reviewed visual workflow can keep the sequence understandable. | Use code when the notification policy is shared and already maintained there. |
| An approval waits for a named reviewer | Keep the wait and its ownership explicit; verify restart behavior. | A service can own persistent approval state and expose it to the workflow. |
| A supplier must be created only once | Call a destination that can reject or reconcile a repeated request. | Put the business uniqueness rule and result receipt in the owning service. |
| A downstream app changes its payload | Review affected nodes and representative execution fixtures. | Validate the integration contract and test its adapter. |
| No engineer is available overnight | Provide a safe operator recovery path; visual history alone is insufficient. | Provide a runbook and operational interface; a repository alone is insufficient. |
Check the result beyond the green execution
An October 6, 2026 r/n8n discussion asks how to catch workflows that say 'Success' when the expected action did not occur. It is a useful operational question, not a measured failure rate. Define success from the business record, then check whether the automation actually reached it.
In the onboarding example, success means the correct approved supplier exists, is linked to the request and has a recorded outcome. A completed HTTP node may only establish that the next system accepted a request. It may still be processing it, or the workflow may have followed a branch that intentionally skipped creation.
Give the operator a receipt they can inspect: request ID, current state, destination record reference and last verified transition. Keep diagnostic detail access-controlled and avoid copying full documents into routine alerts. If the receipt disagrees with the execution status, the operator should know which system owns the final decision.
Which part of your process needs a clearer recovery path?
Share the trigger, intended outcome and the steps that can partially fail. We can compare a workflow, custom service or hybrid around your operating needs.
Rehearse three partial failures before choosing
First, interrupt the process after documents arrive but before approval. The request should remain pending and recoverable without asking the supplier to start again. Second, interrupt it after the supplier record is created but before the notification. Recovery should not create another supplier. Third, make the destination timeout after receiving a create request. A timeout leaves uncertainty; check for the existing result before repeating the action.
n8n supports an error workflow for failed executions. Configure that path deliberately, then demonstrate that the responsible person receives enough information to take the next step. An alert is useful only if the process has a recoverable state and someone is responsible for it.
Use the same exercises for a code implementation. Custom code can also lose work, repeat side effects or report an incomplete result as success. Compare the evidence from the actual designs rather than assuming the platform name settles the question.
Price the operating work, not just the initial build
Prepare a worksheet with setup, workflow changes, hosting, connected-service usage, monitoring, upgrades, recovery support and handover. Add the hours your own team spends approving changes and correcting exceptions. Keep each figure tied to an actual quote or labeled assumption; there is no reliable universal monthly price for this process.
For self-hosting, name who maintains the database, credentials, backups and runtime. n8n's documented queue mode uses separate workers with a shared database and Redis. That can support scaling, but adds components to operate. Measure a representative workload before adding machinery solely because it appears in a production diagram.
For a custom service, include the integration adapters and the operator's recovery interface in the scope. For a hybrid, include the contract between the two systems. Otherwise a cheap initial quote can omit the exact work you will need when a request becomes stuck.
Confirm the use model and extract one difficult step
n8n is distributed under license terms that place conditions on its use. Review the current license for the deployment you intend, especially if customers will access the automation platform or it becomes part of your commercial product. Internal automation and offering a platform to others are different decisions; obtain clarification for your exact scenario when needed.
If your current workflow is already useful, choose one troublesome boundary for a pilot. In the supplier example, move supplier creation behind a reviewed interface while keeping intake intact. Run the revised flow in a test environment and compare approved outcomes, unresolved cases and operator effort. Retain a rollback path during the change.
The resulting decision record should explain who operates the flow, who owns business state, how partial work is resumed and what evidence supports the choice. MUBBITS can help turn that record into a focused automation scope, whether the final answer uses n8n, a service or both.
Frequently asked questions
Does a production workflow have to leave n8n?
No. Decide from your requirements and verified behavior. A clear workflow with suitable recovery and ownership can remain useful. Extracting a particular rule or state transition may be enough when one part becomes difficult to maintain.
Will custom code always cost less at scale?
No. Compare actual workload, service usage, maintenance, operator effort and support. Moving to code introduces integration and operating work of its own; a price claim needs explicit assumptions and evidence.
What should a first pilot demonstrate?
One complete useful outcome and recovery from a partial failure. For supplier onboarding, demonstrate that an approved request creates the correct supplier once and can resume safely when notification or delivery fails.
Let’s work through your next step.
Tell us what you’re building, what you’ve tried, and where you need a hand. We’ll work with you to define a practical way forward.