When an AI feature is not worth building
Decide whether an AI feature is worth funding by measuring the current workflow, usable output, review effort, adoption, and operating cost.

On this page
An AI project is worth funding when its usable results create enough value to cover delivery, operation, and the work people still need to do. A successful demo or a lower token price does not establish that return.
Start with a real workflow and a measurable problem. If the current process is unclear, measure it before adding AI. Otherwise you will have no reliable baseline for deciding whether the feature helped.
TL;DR Compare useful output with build, running, review, and correction costs. Test against the current process and simpler alternatives. Stop or narrow the feature if the benefit does not justify the work.
Establish what the work costs today
Record volume, handling time, waiting time, error rates, and rework. Include the people who check or repair the result, not only the person who starts the task.
Distinguish money you can stop spending from time your team can use elsewhere. Saving time does not automatically reduce payroll. It may let a team handle more demand, improve service, or avoid a future hire. Name the expected benefit and how you will observe it.
For a customer-facing feature, define the behavior you expect to change: completed purchases, retained customers, or use of a paid capability. Treat those as hypotheses until the product evidence supports them.
Compare usable work with the full operating cost
Net value over the evaluation period =
realized operational or revenue benefit
- implementation and change costs
- model, tool, and infrastructure costs
- review, correction, and support costsAvoid double-counting the same benefit as both saved labor and increased capacity. State which costs are one-time and which recur.
The AI operating-cost guide explains how to account for completed work. A cheap draft that takes longer to verify than writing it manually may offer little value. Conversely, a relatively expensive call can pay off when it resolves valuable work reliably.

Watch for three reasons a pilot can mislead
The trial uses easier work. A curated set may exclude the ambiguous requests that create most review effort. Include difficult and incomplete cases as well as normal ones.
People compensate for the system. An enthusiastic tester may quietly correct every output. Count that effort, even when the final result looks good.
The feature is available but unused. A technically successful integration has little value if it sits outside the team's workflow. Find out whether the barrier is trust, extra steps, missing context, or a problem the team does not need solved.
OpenAI's evaluation guidance recommends task-specific evaluations. Pair those quality checks with observation of the actual working process.
Keep the non-AI alternative in the comparison
Some tasks need a better form, a fixed rule, or a cleaner integration. Anthropic's agent guidance recommends using simpler solutions where they are sufficient.
Compare those options against the same outcome. A fixed workflow may be easier to verify and maintain when the rules are stable. AI becomes more useful when the task needs judgment over varied input and the remaining error can be managed.
A managed product may also meet the need. The build-or-buy decision should precede a custom implementation when a suitable product already exists.
Set the next funding decision before the trial
| Trial result | Decision to consider |
|---|---|
| Useful output, manageable review, clear adoption | Expand within the tested scope |
| Value concentrated in one request type | Narrow the feature to that work |
| Good model results, poor workflow adoption | Fix the product integration before expanding |
| Costly errors or review consume the benefit | Redesign or stop |
| Unclear baseline or inconsistent labels | Improve measurement before claiming return |
Assign a business owner to those criteria. Include the cost of ongoing ownership, whether internal or external. The SBA's employee-cost guidance is a useful reminder that staffing decisions include more than a salary line.
Do not rescue an unfounded business case with a promised future model discount. Reassess when the facts change, but fund the current proposal from evidence you can explain now.
Test one workflow against the current process, with a named owner and a date to decide whether to continue. Its output should be a funding decision supported by observed work, not another demonstration of what the model can generate.

Sources
- OpenAI: Evaluation best practices
- Anthropic: Building effective agents
- U.S. Small Business Administration: Employee costs
Common questions
How should we calculate an AI project's return?
How should we calculate an AI project's return?
Compare realized value with implementation, operating, review, and change costs over the same period. Explain how time saved becomes capacity, reduced spending, or additional revenue.
Does saving employee time count as a financial return?
Does saving employee time count as a financial return?
It can create useful capacity, but it is not automatically a cash saving. Identify what the team does with the released time and whether the business benefits.
Is there a universal AI cost-to-revenue cutoff?
Is there a universal AI cost-to-revenue cutoff?
No. Acceptable cost depends on the product, margin target, customer value, and other expenses. Evaluate the complete economics rather than using an unsupported percentage rule.
When should we stop a pilot?
When should we stop a pilot?
When the agreed evidence shows insufficient value, unacceptable risk, or adoption barriers that the next investment is unlikely to resolve. Set those decision criteria before running it.


