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.

PhaseAhead··Updated September 28, 2026·3 min read
When an AI feature is not worth building
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 costs

Avoid 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.

A pilot compares verified benefit with delivery, operating, and review costs, then proceeds, narrows scope, or stops based on agreed criteria.

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 resultDecision to consider
Useful output, manageable review, clear adoptionExpand within the tested scope
Value concentrated in one request typeNarrow the feature to that work
Good model results, poor workflow adoptionFix the product integration before expanding
Costly errors or review consume the benefitRedesign or stop
Unclear baseline or inconsistent labelsImprove 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

Common questions

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?

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?

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 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.

Is this AI project worth funding?

Tell us what you're building. We'll take it from there.

or reach us at hello@phaseahead.ai