The build vs buy AI decision comes down to five things: how unique the workflow is, how sensitive the data is, how often it runs, what it costs over 12 to 24 months and who will maintain it. Generic, low-volume jobs belong in a bought tool; workflows that run on your own rules, span several systems and repeat at high volume are worth building. In practice, most marketing teams buy the platforms and build the glue between them.
The hidden costs on both sides
Most build vs buy debates compare a subscription price against a builder’s quote. Both numbers leave out most of the cost.
| Cost | Buy | Build |
|---|---|---|
| Upfront | Setup, security review, training, data migration | Scoping, building, testing, documentation |
| Running | Seats, credits or usage tiers that rise as you grow | Model API usage, hosting, automation platform fees |
| Integration | Connecting it to your CRM, ad accounts and reporting, which vendors often leave to you | Built in, but every connector is yours to fix |
| Change | Vendor roadmap and pricing changes | Model updates, API changes in the tools you connect |
| Exit | Data export, contract terms, rebuilding workflows elsewhere | Key-person risk if the builder leaves |
Two costs get missed most. On the buy side, it’s overlap: tools you already pay for often include AI features, so a new point tool can duplicate something sitting unused in your CRM. On the build side, it’s maintenance: a workflow built in a week can need a few hours a month indefinitely, and nobody budgets for it.
Five questions that decide build vs buy
Run every candidate workflow through these before you look at vendors or quotes.
1. How unique is the workflow?
If most companies do the job the same way (transcribing calls, summarizing meetings, drafting ad copy variants), a vendor has already built it better than you will. If it depends on your own definitions, such as your ICP, routing rules, naming conventions or margin thresholds, a generic tool gets you partway and your team fixes the rest by hand.
2. How sensitive is the data?
Sensitivity cuts both ways. A mature vendor with a data processing agreement, SSO and clear retention terms can be safer than a homemade workflow with API keys pasted into a shared doc. Build wins when data can’t leave your environment or you need to choose which model provider sees it. Either way, send the model only the fields the task needs.
3. What volume will it run at?
Volume moves the math more than anything else. At 50 runs a month, a subscription is cheap and a build rarely pays back. At several thousand runs a month, credit or usage-based pricing can outgrow a workflow that calls a model API directly. Estimate volume a year out.
4. What does it cost over 12 to 24 months?
Buying almost always looks cheaper in month one. Add upfront, running, integration and maintenance costs over the full period and see where the lines cross.
5. Who maintains it?
If nobody can own it, that answer overrides the other four. An unmaintained build is worse than a mediocre bought tool, because it tends to fail silently.
The decision rule: if three or more answers point to build and maintenance is one of them, build. If maintenance points to buy, buy, or pay someone to maintain it.
When off-the-shelf wins
- The task is a commodity. Transcription, meeting notes, background removal, translation. Vendors compete hard here and improve faster than you could.
- The vendor has data you don’t. Enrichment databases, intent signals and review aggregation depend on data collected at scale. You can only build around that.
- It already lives in a tool you pay for. Check your CRM, email platform, ad platforms and analytics tools first. Built-in AI features are often good enough, and the integration is done.
- You’re still testing the use case. A month of a bought tool is cheaper research than a build.
- Stakes and volume are low. A workflow that runs twenty times a month rarely justifies custom work.
The trap is buying one tool per task: five logins, five data silos, overlapping features, and someone still copying outputs between systems by hand.
When a custom workflow or internal tool wins
For most marketing teams, “build” doesn’t mean hiring engineers. It means a workflow on an automation platform that calls a model API, applies your rules and writes results back into your systems. An internal tool, a small app with a review screen, is the step up when people need to approve outputs first.
- Your definitions are the value. Scoring against your ICP, routing by your territories, reporting against your contribution margin. Configuring a generic tool to approximate these is often more work than building.
- The workflow crosses three or more systems. Pull from the CRM, check the ad account, enrich, score, write back, alert the owner. Point tools stop at their own edges, and the glue is where the time savings are.
- Volume makes usage pricing painful. At high volume, paying the model provider directly usually costs less than a vendor’s markup.
- It encodes how you win. If the workflow captures your research process or offer logic, you don’t want it to be a feature competitors can buy.
A hypothetical example: bought research tools produce generic company summaries. A built workflow pulls CRM history, recent site visits and open opportunities, checks them against your ICP and writes the brief in the format sales already uses. Same model; the value is in the inputs and rules. For more candidates, AI agents for marketing rates 12 use cases by build effort and risk.
Hybrid: buy the platform, build the glue
The most durable setup is neither pure build nor pure buy. You buy the platforms that hold data and do the heavy lifting, then build the thin layer that connects them to your rules.
| Layer | Buy or build | Examples |
|---|---|---|
| Systems of record | Buy | CRM, email platform, ecommerce platform, ad accounts |
| Automation platform | Buy or self-host | n8n, Make or Zapier |
| Models | Buy API access | A major provider, chosen for data terms and output quality |
| Business rules and prompts | Build | ICP criteria, routing logic, brand rules, QA checks |
| Connectors and review steps | Build | Data pulls, write-backs, approval queues, alerts |
Small custom work means small maintenance. It also keeps you portable: if a better model appears, you swap the API call and keep the rules. Keep prompts and rules documented outside the automation tool so they survive a platform change. If you’re still choosing that layer, n8n vs Zapier vs Make compares cost at volume, self-hosting and who can realistically maintain each.
Estimating ROI and payback
Keep the math simple and honest:
- Monthly value = hours saved × loaded hourly cost, plus any measured outcome gain
- Monthly net benefit = monthly value − running cost − maintenance time
- Payback in months = upfront cost ÷ monthly net benefit
A hypothetical example with round numbers: a sales team researches 300 accounts a month at 20 minutes each, 100 hours at a loaded $60 an hour. The bought tool saves less because its briefs need reformatting; the build fits the team’s format but costs more upfront.
| Buy | Build | |
|---|---|---|
| Upfront cost | $1,000 (setup, training) | $8,000 (build, testing) |
| Hours saved per month | 60 | 80 |
| Value of hours saved | $3,600 | $4,800 |
| Running cost per month | $800 (8 seats) | $900 ($200 API and hosting, $700 maintenance time) |
| Net monthly benefit | $2,800 | $3,900 |
| Payback | Under 1 month | About 2 months |
| 12-month net value | $32,600 | $38,800 |
At this volume, build wins. Now halve it. The bought tool still costs $800 in seats and saves 30 hours, netting $1,000 a month. The build saves 40 hours and, with slightly lower API spend, nets $1,600. Build payback stretches to five months, and 12-month value is roughly a tie: $11,000 for buy, $11,200 for build. Build only pulls clearly ahead over two years ($30,400 vs $23,000), and only if the owner and the workflow last that long.
Three rules keep the estimate honest:
- Count only redeployed hours. Saved time is value only if it goes somewhere useful.
- Measure, don’t trust demos. Time a two-week pilot with your own team and data.
- Set a kill criterion. My rule of thumb is payback within about six months on conservative numbers. Review at 90 days; if the workflow misses, fix it or switch it off.
Who maintains it after launch
Every AI workflow degrades without an owner. Model updates shift outputs, connected APIs change, credentials expire, source data drifts, and costs creep when a loop runs too often. Bought tools push some of this onto the vendor; builds push all of it onto you.
Before launching anything, bought or built, confirm:
- A named owner with monthly time budgeted, not “the team”
- Alerts for failed runs and cost spikes, sent somewhere a person reads
- Weekly review of sample outputs for the first month, then monthly
- A short runbook: what it does, where the rules live, how to pause it, the manual fallback
- Spending limits or usage alerts on every model API account
- For bought tools, a tested data export and the renewal date on a calendar
If you can’t tick the first box, the decision is made: buy a supported tool, or have someone build and maintain it for you. That’s how I run AI automation engagements: build the workflow, run it with the team for the first weeks, then keep maintaining it so it doesn’t quietly break.
Get it built
If you have a stack of AI tools on trial and no clear answer on which to keep, cut or replace, I can sort it and build what’s worth building. The AI automation add-on starts at $2,500/mo, and the Growth Audit is $1,500 fixed and credited if we continue. See pricing or get in touch.