Post: The Build Step Is Already Commoditized. Here’s What That Means for Your Automation Budget.
I’ve been building automations since 2007. I’ve watched this industry price itself like a custom software shop for most of that time — hourly rates for every scenario, fixed fees per workflow, retainers that bundled discovery and build and support into one undifferentiated number. That model made sense when building was hard. It doesn’t anymore.
Here’s my thesis, plainly stated: the build step in automation is already commoditized. If your consultant is quoting you a fixed price per scenario without separating what they’re actually charging for, you’re paying a premium for something AI can now do in minutes. I documented how this plays out in practice in our Make + Claude field report — including what the MCP gets right and where human expertise still matters. Read that first if you want the technical foundation. This post is about what it means for your budget.
What Does “Commoditized” Actually Mean?
Commoditized doesn’t mean worthless. It means the cost to produce something has dropped to the point where it’s no longer a meaningful differentiator. Compute is commoditized. Storage is commoditized. Basic web hosting is commoditized. That doesn’t mean you don’t need them — it means you shouldn’t pay custom-fabrication prices for them.
The build step in Make.com automation is heading the same direction. When I hand our Make MCP a well-described scenario — including the relevant API docs for tools without native modules — it produces a complete, working scenario. Correct HTTP module structure. Routed error handlers. Proper JSON payloads. No broken modules. Not a rough draft I fix for an hour. A working build.
The key phrase there is “well-described.” I’ll come back to that. But the point stands: the mechanical act of assembling a Make scenario is no longer where the time or expertise lives.
Where Has the Value Always Been?
Discovery and support. Full stop.
The OpsMap™ phase — figuring out what to automate, in what order, and why — has always been the hardest work I do with a client. It requires understanding their business model, their data flows, their staff dynamics, and their tolerance for change. No AI tool walks into a business and produces that map. A client can’t produce it themselves, which is why they hire me.
The OpsCare™ phase — keeping automations running, catching errors before they compound, maintaining integrations as APIs change — has always been what separates a working system from an abandoned one. Most automation projects fail not because the build was wrong but because nobody owned the system after launch.
AI just compressed the middle step. That means OpsMap and OpsCare are more important now, not less — because the bottleneck moved. When build was slow and expensive, it ate the budget. Now that it isn’t, the budget should follow the value.
What This Means for Your Automation Budget
- Per-scenario pricing is a red flag. If a consultant quotes you $X per workflow without breaking down discovery, build, and support, you’re buying a bundle where the most expensive line item is now the cheapest to produce.
- Discovery should get more budget, not less. The OpsMap process determines whether your automations solve the right problems. A bad map with a fast build is still a bad outcome.
- Change management is chronically underfunded. I see it constantly. A beautifully built automation that nobody uses because the team wasn’t trained and the process wasn’t adjusted. That’s a budget allocation problem, not a build problem.
- OpsCare is where ROI compounds. The TalentEdge case generated $312K in annual savings and a 207% ROI. That didn’t happen because the scenarios were built fast — it happened because the system was maintained, refined, and expanded over time.
- The “AI will do it free” assumption is dangerous. Commoditized doesn’t mean free. It means you should know exactly what you’re paying for and why.
Isn’t Complex Build Work Still Worth Paying For?
Yes — and this is the counterargument I want to be fair about, because it’s real.
Not every automation scenario is a straightforward three-module webhook-to-CRM workflow. We build integrations involving custom API structures, multi-branch logic, conditional routing across eight or ten paths, and error handlers that do meaningful work — not just send a generic alert. That kind of build still requires expertise. The MCP accelerates it, but it doesn’t replace the judgment that goes into designing it.
There’s also the description problem. The MCP builds exactly what you describe. If you describe it vaguely, you get a vague build. Writing a precise scenario description — one that captures edge cases, specifies data structures, and anticipates failure modes — is itself a skilled task. Someone has to do that work well. It doesn’t disappear; it shifts upstream.
So the counterargument isn’t wrong. Complex builds still need expertise. What I’m pushing back on is the assumption that all build work warrants the same premium pricing, and that build complexity is the primary driver of automation value. It isn’t. The complexity that matters most is upstream, in discovery, and downstream, in maintenance.
If you want to see exactly where AI performs well and where it still needs a skilled hand, the breakdown in our five automation tasks AI handles well — and five it gets wrong is worth your time.
What Should You Do Differently?
Here’s how I’d restructure an automation engagement budget given where things stand in 2026.
1. Demand line-item clarity from your consultant. Ask them to separate discovery, build, and ongoing support in their proposal. If they can’t or won’t, that tells you something. The ones who resist transparency on this are usually the ones whose pricing depended on bundling a commoditized step with the valuable ones.
2. Weight discovery at 30-40% of initial project budget. I know that sounds high if you’re used to paying mostly for build. But a well-run OpsMap session determines whether you automate the right things. Getting that wrong and then building fast is just failing faster.
3. Build in OpsCare from day one. Not as an afterthought. Not as “we’ll revisit in six months.” Automations degrade. APIs change. Business processes shift. The system that runs clean on launch day will drift without someone watching it. Budget for that watch.
4. If you’re considering DIY, be honest about the description problem. AI tools are powerful but they’re not psychic. If you can’t describe precisely what you want — including the edge cases and failure paths — you’ll produce scenarios that work 80% of the time and fail quietly the other 20%. The DIY vs. hiring a Make partner breakdown covers this in more detail. Read it before you decide.
5. Stop paying for scenario count as a proxy for value. Ten well-designed automations that solve the right problems are worth more than fifty that automate the wrong ones. If your consultant is upselling you on volume, your incentives are misaligned.
The Bottom Line
The build step is commoditized. That’s not a threat to good automation consulting — it’s a clarification of what good automation consulting actually is. Discovery. Strategy. Change management. Production support. Those are the things AI doesn’t do and can’t replace.
If your budget is still weighted toward paying per scenario, reallocate. Put more into understanding what to build before you build it, and more into keeping what you build running after it’s live. That’s where the ROI lives — and that’s where it’s always lived.
Keep Automating,
Jeff Arnold
Founder & CEO, 4Spot Consulting | Make Gold Partner
Information in this article is deemed to be accurate at time of publishing. 4Spot Consulting reviews and updates content periodically as best practices evolve.
Frequently Asked Questions
What does it mean that the automation build step is commoditized?
It means the mechanical work of assembling an automation scenario — connecting modules, writing JSON, formatting API calls — can now be done by AI tools in a fraction of the time it used to take a human. The cost to produce that work has dropped dramatically. That doesn’t make it worthless, but it does mean you shouldn’t pay custom-fabrication prices for it when AI can produce the same output in minutes.
Should I stop paying automation consultants for build work entirely?
No. Complex builds — multi-branch logic, custom API integrations, sophisticated error routing — still require expertise. What’s changed is that not all build work warrants the same premium, and build complexity is no longer the primary driver of automation value. Discovery and production support matter more than they’ve ever been credited for.
Where should I reallocate my automation budget?
Weight 30-40% of your initial project budget toward discovery — specifically the process of mapping what to automate and in what order. Budget for change management and team training. And build OpsCare into the engagement from day one, not as an afterthought. That’s where automation ROI compounds over time.
What is the “description problem” with AI automation tools?
AI builds exactly what you describe. Vague input produces vague scenarios; specific input produces specific, working builds. Writing a precise scenario description — one that captures edge cases, data structures, and failure modes — is itself a skilled task. That work doesn’t disappear when AI enters the picture; it shifts upstream into the discovery and scoping phase.
How do I know if a consultant’s pricing reflects the commoditized build step?
Ask them to separate discovery, build, and ongoing support as line items in their proposal. If they quote you a flat per-scenario price without that breakdown, you’re likely paying a bundled rate where the most expensive component is now the cheapest to produce. Transparency on this is a basic credibility signal.
Is DIY automation a viable alternative given AI tools?
For simple, well-defined workflows — yes, more than ever. But the description problem is real. If you can’t specify your scenarios precisely, including edge cases and failure paths, AI tools will produce scenarios that work most of the time and fail quietly the rest. The decision depends on your technical comfort with that precision, and on whether you have someone to own production support after launch.
