A Quickstart for Measuring the ROI of a Custom AI App

Key Takeaways

• Measure the workflow before you build the app. Without a timed baseline, every ROI number after launch is a guess with a decimal point.
• The math fits on an index card. Runs per month, minutes saved per run, loaded hourly cost, adoption rate, and the full cost to build and run the app.
• Adoption goes inside the formula. An app that 40% of the team uses has less than half the value of one that 100% of the team uses, and it pays back on a very different clock.
• Running costs never stop. Model calls, hosting and maintenance belong in the denominator every month, not only the build invoice.
• Decide the kill line before launch. Check at 30, 60 and 90 days, and agree up front what number means you fix it, scale it or shut it down.

Most ROI cases for a custom AI app get written exactly once: in the deck that gets the budget approved. Then the app ships, people start using it (or don't), and nobody opens that spreadsheet again until someone in finance asks what the company got for the money.

That pattern shows up in the big surveys. In IBM's 2025 CEO study of 2,000 CEOs, respondents said only 25% of their AI initiatives delivered the ROI they expected over the last few years, and only 16% scaled across the enterprise. Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, and unclear business value is one of the reasons it names.

I read those numbers less as "AI doesn't work" and more as "nobody wrote down what working would look like." A custom app makes that worse in one way and better in another. Worse, because you pay to build it before you see any value. Better, because a custom app does one specific job for one specific team, and specific jobs are easy to measure if you start before the first line of code.

So this is a quickstart. One formula, one worksheet, one worked example, and three checkpoints. You can do the first pass in an afternoon.

Your ROI Case Starts Before the First Line of Code

The most common mistake is measuring only after launch. By then, nobody remembers how long the old way took, and the estimate gets made by the people who want the project to look good (including, sometimes, the people who built it).

A custom AI app almost always replaces or speeds up a workflow that already exists. Someone reads contracts. Someone reconciles invoices. Someone searches three systems to answer a customer question. That work has a cost today, and you can measure it this week.

Time the current workflow for two weeks

Pick five to ten people who do the work. For two weeks, track three things: how many times the task happens, how long each one takes, and how often it has to be redone. A shared spreadsheet is fine. Don't round. "About 15 minutes" turns into 20 when you watch it.

Those two weeks give you the baseline every later number depends on. Skip them and you will spend month three arguing about the before, not the after.

The Whole Formula Fits on an Index Card

ROI for a custom AI app comes down to two lines: what the app returns each month, and what it costs to have it.

Monthly value = runs per month × adoption rate × minutes saved per run ÷ 60 × loaded hourly cost

Monthly cost = (runs per month × adoption rate × cost per run) + hosting and maintenance

Payback (months) = build cost ÷ (monthly value − monthly cost)

Year-one ROI = (annual value − annual running cost − build cost) ÷ (annual running cost + build cost)

That's it. Time saved is usually the biggest value line. If the app also cuts errors, rework or lost revenue, add a second value line for that, but only if you measured it in the baseline.

Fill in the worksheet

Adoption Belongs Inside the Equation

This is the part most ROI cases leave out, and it is the part that moves the answer most.

A custom app has a value ceiling the day it ships: the number of times the workflow happens. What you actually get is that ceiling times the share of people who use the app instead of the old way. Launch announcements count seats. ROI counts runs.

Fortune's write-up of MIT's NANDA research found that about 95% of enterprise generative AI pilots delivered little or no measurable impact on profit and loss, and it put much of the blame on integration: tools that "don't learn from or adapt to workflows." I'd put it more plainly. An app nobody opens has an ROI of negative one hundred percent, no matter how good the model is.

Count runs, not logins

Track adoption as completed runs through the app divided by total runs of the workflow. Logins tell you someone was curious. Completed runs tell you the work moved. If the app sits beside the old process instead of inside it, adoption stalls around the people who were excited on day one.

Running Costs Keep Going After Launch

The build invoice is the cost everyone remembers. It is also the only cost that ends.

Every run of a custom AI app costs something: model calls, retrieval, compute, logging. Then there is hosting, monitoring, and the steady trickle of fixes when a source system changes or users find an edge case. These belong in the monthly cost line from day one. Leave them out and your payback date drifts every quarter.

Price one run before you price the app

Before launch, run the app on 50 real examples and record the average cost per run, including retries and the longest documents in the set. Multiply by your expected monthly runs. If that number surprises you, it's much cheaper to fix the design now (smaller model for simple steps, less context per call) than after the bill arrives. This is also why every PressW build ships with usage dashboards and eval suites: you can't manage a cost you can't see.

A Worked Example: Payback Depends on Adoption

Here is the formula with numbers in it. These are illustrative, chosen to make the math easy to follow, not drawn from a real client or from PressW pricing.

Say a finance team processes 2,000 vendor documents a month. The baseline shows each one takes about 12 minutes longer by hand than with the app, and the loaded hourly cost is $60. The app costs $150,000 to build, $0.40 per run to operate, and $3,000 a month to host and maintain.

At 70% adoption:

• Monthly value: 2,000 × 0.70 × 12 ÷ 60 × $60 = $16,800
• Monthly cost: 1,400 runs × $0.40 + $3,000 = $3,560
• Payback: $150,000 ÷ $13,240 ≈ 11 months
• Year-one ROI: about 5%. Year two, with no build cost, is about 370%.

That year-one number is thin, and that's honest. Custom apps are front-loaded. The case gets made in year two and beyond.

Now change one input. Keep everything else the same and move adoption:

Same app. Same build cost. Same model. Payback moves from seven months to two years based on whether people use it. That's why I spend more time on rollout, training and fitting the app into the existing workflow than on the model choice.

Set the Kill Line Before You Ship

Here's a rule that sounds harsh and saves a lot of money: decide what failure looks like before launch.

Most stalled AI apps don't fail loudly. They just keep running at 30% adoption, costing a few thousand a month, with nobody willing to call it. Agreeing on thresholds in advance turns that into a scheduled decision instead of an awkward one.

Check at 30, 60 and 90 days

• Day 30: Is it being used? Look at adoption and completed runs. Low numbers here usually mean a workflow fit or training problem, which you can fix.
• Day 60: Is it saving the time you expected? Re-time a sample of runs with the app and compare to the baseline. Check the quality of the output too. Time saved on work that gets redone is not time saved.
• Day 90: Is it on track to pay back? Plug real numbers into the formula. Then make the call: scale it to more teams, fix the specific gap, or shut it down.

The honest part: I don't think anyone has a clean method yet for valuing the softer gains, like better decisions or faster answers for customers. I'd still rather start with the hours you can measure and add the rest when you have evidence, than lead with a big number nobody can check.

One more caveat from that same MIT research: it found that buying from specialized vendors and building through partnerships succeeded about 67% of the time, while internal builds succeeded only a third as often. I run a company that builds custom apps, so read my take with that in mind. My read is that the build path works when the workflow is specific to your business and the measurement starts on day one. It fails when it's a science project with no baseline.

Measure It Like an Investment, Because It Is One

A custom AI app is a capital decision. It deserves the same treatment as any other: a baseline, a forecast, a payback date and a review.

The good news is the measurement is not hard. Two weeks of timing the current workflow. Seven numbers in a worksheet. Three check-ins after launch. Most of the teams I talk to could do the first pass this week.

The ClinicalNet case study is a good example of the kind of number this produces: PressW built a clinical trial search engine and estimates it saved 1,000+ hours of manual work. That's the line you want on the slide, and you can only write it if you counted the hours first.

If you're scoping a custom app and want a second set of eyes on the baseline or the formula, that's work we do at the start of every engagement through PressW's Custom AI Application Development service. If you want to compare notes on a specific workflow, Book a Discovery Call.

FAQ