.png)
Most manufacturers who are ready to automate make the build vs. buy vs. hire decision based on budget. That is the wrong first variable.
A low-cost platform that no one maintains in month six is more expensive than a properly scoped partner engagement. An in-house build that ties up a developer who also owns five other things produces a six-month timeline and a half-built automation. A partner engagement on a workflow that isn't documented yet produces a well-built automation of a poorly understood process.
The right first variable is not cost. It is who will own and maintain this six months from now.
Each path works. Each path also has a specific failure mode. The manufacturers who choose correctly are the ones who match the path to their actual operational conditions, not to a budget target or a vendor's pitch.
You have a developer (or a technically capable operations person) who builds and maintains the automation using a platform like n8n, Retool, or a custom code stack. The automation is owned internally from day one.
Best fit when:
Watch out for:
The shared developer problem. If the person building the automation is also responsible for other systems, automation work gets deprioritized every time something more urgent comes up. A first build that takes three months to ship because the developer kept getting pulled away is a failed first build, regardless of how good the automation is when it finally ships.
The tribal knowledge problem. An automation built by one developer, without documentation, is as fragile as any other system built by one person. If that developer leaves, the automation is effectively unmaintained. Build documentation requirements into any in-house build process from the start.
Who owns it after: The internal developer. This is the best ownership situation when the developer has the time and the workflow is well-understood.
You subscribe to a platform (n8n cloud, a managed automation service, or a workflow tool like Zapier or Make) and configure workflows yourself or with minimal external help. The platform handles the infrastructure. You handle the logic.
Best fit when:
Watch out for:
The connector gap. Every major automation platform has hundreds of native integrations. Your ERP almost certainly is not one of them. When the workflow requires connecting to a legacy ERP, a custom database, or a system with a non-standard API, the "buy a platform" path often requires the same custom development work as a build-in-house path, but with the added constraint of working within the platform's architecture.
The unmaintained workflow problem. Buying a platform and building workflows on it is fast to start. It is also fast to let those workflows drift. Platform updates change behavior. API endpoints change. Business processes change. Someone needs to actively maintain the workflows, test them when connected systems update, and retire them when they are no longer relevant. If no one is assigned to that maintenance, the automation gradually degrades until it fails.
Who owns it after: The person who configured it. If that person leaves, ownership transfers to whoever takes over their role. This is a manageable situation when the configuration is well-documented and the platform is accessible to non-developers.
You engage an automation engineer or agency to scope, build, and hand off the automation. The partner builds it. Your team owns and maintains it after handoff.
Best fit when:
Watch out for:
The undocumented workflow problem. A partner can only automate what is documented. If the workflow exists primarily in someone's head, the partner will either build an automation of an incomplete process or spend significant time in the scoping phase extracting the process before they can begin. Either situation extends the timeline and the cost. Complete the process documentation before engaging a partner.
The black box problem. A partner engagement that produces a working automation without documentation produces the worst long-term outcome: an automation your team depends on but cannot maintain, diagnose, or modify. Before signing any engagement, confirm what documentation is included in the deliverable and ask to see an example from a previous project.
The pricing logic gap. For manufacturing and distribution workflows specifically, the automation often depends on business rules (pricing tiers, credit terms, discount schedules) that have never been formally documented because they have always been applied by the person who knows them. A partner cannot encode rules that haven't been written down. Surface the pricing and business logic documentation requirements early.
Who owns it after: Your internal team. This is the right outcome when the partner delivers a runbook and the internal team has been trained to monitor and escalate issues. It is the wrong outcome when the partner delivers a system no one internally understands.
Three questions point toward the right path for your situation. Answer them for the specific workflow you are considering, not for automation in general.
Question 1: Does your team have a developer with 20 or more hours per week available specifically for automation work?
Yes: Build in-house is viable. Evaluate whether the workflow complexity matches the developer's experience and whether the documentation requirements are built into the project.
No: Rule out build in-house for this workflow. The shared developer problem produces slow, incomplete builds that lose internal credibility. Move to the next question.
Question 2: Does your ERP (or primary data source) have a documented REST API with native connectors on your preferred platform?
Yes with native connectors: Buy a platform is worth evaluating. Confirm someone internally will own and maintain the configuration.
Custom integration needed: Buying a platform for a workflow that requires custom ERP integration adds platform constraints without reducing development complexity. Hire a partner.
Question 3: Who will maintain this in month six?
Internal developer with time: Build or buy.
No one identified: Do not build until this is resolved. An unmaintained automation is a liability, not an asset. If the answer is "no one," engage a partner who includes a maintenance agreement in the scope, or delay the build until an internal owner is identified.
A mid-market distributor wants to automate their customer onboarding workflow. The workflow connects a web form, a credit check API (Experian B2B), their ERP (Epicor), and their customer portal.
Question 1: They have one developer, but he also manages the ERP, the WMS integration, and the company's internal tooling. He has roughly 5 to 8 hours per week available for new projects. Build in-house is ruled out.
Question 2: Epicor has a REST API, but it is not natively supported by any major automation platform. The credit check API is straightforward. The ERP connection requires custom work. Buy a platform is ruled out for this specific workflow.
Question 3: The VP of Operations has agreed to own the automation post-handoff, with the developer available to escalate technical issues.
Result: Hire a partner. The partner builds the ERP integration and the n8n workflow, delivers a runbook and error log structure, and trains the VP of Operations on how to monitor and escalate issues. The developer is available for escalations but is not the primary owner.
Run the three questions for your highest-priority workflow. Where does it point?
If it points clearly to one path, start there. If it points somewhere that feels wrong given your constraints, the constraint is usually worth surfacing before the build starts rather than after.
The right path is the one that produces an automation your team can actually maintain. Everything else is secondary.
If you are still unsure after the framework, that is exactly what the free call is for
.png)
