Calculate ROI by comparing what the manual process actually costs today (fully-loaded labor, error correction, missed volume) against the one-time build cost plus ongoing per-run inference cost, then solve for the volume where those lines cross. If that break-even point is inside your realistic 12-month volume, build it. If it isn't, don't.
Most founders skip this and instead ask "is AI worth it," which isn't answerable. The answerable question is narrower: does automating this specific task, at this volume, pay back faster than the cash and attention it costs to build and run. Here's the framework we use before scoping any agent project.
Step 1: Price the manual baseline honestly
Take the task the agent would replace and cost it out the way a CFO would, not the way an optimist would.
- Fully-loaded hourly cost of whoever does the task now (salary + benefits + overhead, not just base pay)
- Time per unit: minutes to draft one outreach email, triage one support ticket, extract one invoice
- Error cost: rework, refunds, or missed follow-ups caused by human inconsistency at volume
- Opportunity cost: work that doesn't happen because a person is stuck doing the repetitive task instead
Multiply time-per-unit by your monthly volume and you get a real monthly cost for the status quo. This number is the target the agent has to beat, and it's usually higher than people expect once error cost and opportunity cost are included.
Step 2: Price the agent, not just the model
Two cost lines, and teams routinely forget the second one:
Build cost (one-time): scoping, prompt/eval iteration, integration with your systems, and the first month of monitoring while you tune it. For a well-scoped single-purpose agent this is usually the bulk of what you'd budget in an MVP timeline, not a multi-quarter platform build.
Run cost (ongoing, per unit): inference tokens, any tool/API calls the agent makes, plus maintenance as prompts drift and models get swapped out. Get this number from a real test batch, not a spec sheet. Run 100-200 real inputs through the actual prompt on the actual model and take the average cost per run. Guessing here is where ROI math falls apart, because agent costs compound with volume in a way flat SaaS subscriptions don't.
One thing worth deciding early: whether the task needs a multi-step agent chain or a single well-designed call. We run our own outreach system on a single-call pattern: one model call that reads a scraped page and produces both the extracted facts and the drafted email, instead of a multi-step chain that extracts, then summarizes, then drafts. It came out cheaper per unit and more consistent in output, because there were fewer places for the process to drift or fail silently. If your task can be scoped that tightly, your run cost drops and your break-even point arrives sooner. Worth reading before committing to an architecture: single-call vs agent chains.
Step 3: Find the break-even volume
With both cost lines in hand:
Break-even volume = Build cost / (Manual cost per unit - Agent run cost per unit)
If manual cost per unit is $4.50 (labor + error cost) and agent run cost is $0.15, your savings per unit is $4.35. A $6,000 build cost breaks even at roughly 1,380 units. If you're doing 2,000 of those units a month, you're profitable inside month one. If you're doing 200 a month, you're looking at seven months, which changes the calculus, especially if the process might change before then.
This is also where you catch the projects that shouldn't be built. Low-volume, highly variable tasks (the exception-handling, judgment-heavy 20%) rarely clear break-even and are usually cheaper to leave with a human.
Step 4: Model the second-order effect, not just the cost swap
Cost savings alone often undersells the case. The better ROI usually comes from volume the agent unlocks that a human never had time for. In our own cold-email tool, the win wasn't just cheaper drafting, it was that we could personalize every single email instead of batching generic ones, which is a volume/quality tradeoff a human team can't make at scale. Separately, we found that changing the call-to-action from a calendar booking link to a soft "reply YES" consistently lifted reply rates, because scheduling friction was killing interest from people who were otherwise ready to engage. Neither of those shows up in a pure cost-per-unit calculation, but both moved the actual number that mattered: revenue per dollar spent on outreach.
When you're scoping ROI, ask what becomes possible at the new cost and speed, not just what gets cheaper.
Step 5: Set a kill threshold before you start
Decide upfront what "not working" looks like: a break-even date, an accuracy floor on evals, or a cost-per-unit ceiling. Write it down before the build starts, not after you're three months in and emotionally invested. This is the single biggest difference between teams that get real ROI from agents and teams that keep funding a project because stopping feels like admitting failure.
The short version
Cost the manual process honestly, price the agent's build and run cost from real test data, solve for break-even against your real volume, and decide in advance what would make you kill it. Volume and repeatability are what make agent ROI work, not the novelty of the technology.
If you want a second pair of eyes on whether a specific workflow clears that bar before you spend build budget on it, let's talk.
Originally published on the Pykero blog.
This article was originally published by DEV Community and written by Pykero.
Read original article on DEV Community