An agency just quoted you a custom app. The deck was good, the room nodded, the number was high but not absurd. Before you sign, count the things you already pay for that nobody has ever opened, most of the time the answer is in that list, not in the build deck. You don't need an app: you need a quiet hour with the systems you already own and someone willing to argue the cheaper case. This is what that hour sounds like.
An app is an operational system you've agreed to own for ten years. That's the part the proposal never names. The build is six figures and six months; the next decade is what makes the build a decision. After the launch, an app needs hosting, monitoring, an on-call rota, three rounds of OS upgrades that break things, a redesign when iOS or Android changes the screen, a stack of compliance affidavits when a client asks, and someone whose Wednesday is now reviewing the crash log. None of those costs are in the build estimate. All of them outlive whoever signed for it.
The current pressure to build is loud because the build itself looks cheaper than ever. AI tooling has dropped first-draft software cost to the point where a freelance developer can scaffold a mobile app over a weekend, and an agency will quote a hardened version of that scaffolding for thirty to a hundred and twenty thousand. The pitch lands because the buyer is comparing build prices, not lifetime prices. The buyer is also rarely the person who'll be paying the lifetime bill, that person is the operations manager three rows over, who isn't in the room.
So before we ask whether you need an app, we ask whether you can already do the thing without one. The next three sections are the test we run on every app proposal we see. It's deliberately not interesting. The point is to be the boring grown-up in the room.
Signs the app is the wrong tool
The clearest signal is that the proposal solves a desktop problem with a phone. If the actual users, your dispatchers, your accountants, your store managers, sit at desks during the working day, a mobile app is a strange answer to their problem. Web is faster to build, faster to fix, free to install, and renders fine on a phone if a hands-free moment ever arrives. Pitch decks like the visual of an icon on a home screen. Operations doesn't open the app once a quarter.
Another sign: every named feature in the proposal exists, today, in a SaaS tool you already pay for. Salesforce has a mobile client. So does HubSpot, NetSuite, QuickBooks, Microsoft 365, Google Workspace, your accounting package, your point-of-sale, and the field-service vertical SaaS you bought in 2021. If your custom app's spec is a worse version of those clients with a logo on it, you are building a polo shirt that you could have bought.
A third sign is that the agency cannot name the one person whose Tuesday improves on day one. They will tell you customers will love it, that staff will be more efficient, that the brand will benefit. They won't name a human and a task. If a build can't be reduced to “Person X stops doing Y on launch day,” it is not yet a project, it's a wish, and wishes are remarkable at finding ways to cost a quarter million dollars.
A fourth sign is that the proposal's value rests on a behaviour change. “Customers will open the app weekly to track their loyalty points.” They won't. Loyalty apps die in the second screen of the home folder; you'll spend years pushing notifications to convince people to keep them installed, and even then the median open rate is in single digits. If the app needs people to change their habits to make sense, the app is not the lever. The habit is, and apps are a slow, expensive way to move a habit.
A fifth sign is that the urgency in the room came from outside it. A competitor launched something. An investor remarked on it. A board member's daughter said something at dinner. These are not strategic pressures; they are conversational ones. Custom software built to win conversations costs the same as software built to solve problems, and is more likely to be wrong.
When an app IS the right answer (the shorter list)
Three patterns reliably justify a custom app. The first is that the work itself happens on the move, hands occupied, signal patchy, gloves on, camera needed at the point of action. Field service, inspections, delivery, frontline retail. Web doesn't cut it because the device's offline cache, camera, GPS, or hardware integration is the feature. A custom app is then not the marketing decision, it's the tool.
The second is that you have a process so specific to your business that no SaaS will ever bend far enough to fit it, and the cost of the manual workaround is large and visible (six figures of staff time annually, or the loss of a contract). In those cases, custom software pays back inside two years, and the build is the cheapest part of the math. Worth the lifetime bill.
The third is regulatory: a workflow that requires audit trails, e-signatures, jurisdictional data residency, or proof that data didn't pass through a generic vendor's logs. The off-the-shelf stack can't meet the bar without contortions, and the contortions are themselves a custom build wearing a different invoice. In which case, build it and own it cleanly.
Notice what isn't on the list. There is no “our customers will expect an app from a brand of our size,” because that expectation, as measurable behaviour, doesn't exist. There is no “our competitors have one,” because your competitors' apps are mostly being quietly decommissioned. There is no “we need the data,” because the data you want is already in the SaaS you're paying for, you just haven't asked it for the report.
What to do instead
If you've made it through the five signs and the shorter list still doesn't apply, the cheapest next move is almost always a configuration audit of what you already own. Open the SaaS tools you pay for monthly. Open the dashboards nobody has opened in eighteen months. Open the integration marketplaces, Zapier, Make, your accounting tool's app store, your CRM's app exchange. Most “we need an app” problems are an unused report module, a webhook that was never wired, or a setting that was left at default in 2022. The fix is hours, not months.
If the audit doesn't close the gap, the next move is a single integration. Not a platform, not a build, one piece of glue between two systems you already pay for, that removes the human keying numbers from one to the other. Integration work is the highest return per dollar in operational software, and it never makes the cover of an agency deck because there's not much to charge for. We've seen ten-thousand-dollar integrations remove problems that fifty-thousand-dollar discovery phases had been written about.
If integration doesn't close it, the next move is a quiet web app, internal-only, no installer, no app-store review, no native footprint. Built once, hosted on the same domain as your marketing site, accessible to staff with the same login they already have. This is what most “we need an app” conversations should have been: a screen, a form, and a database, behind a password. It's two weeks. It can be killed cheaply if it's wrong. It can scale into the bigger thing if it's right.
Only after those three honest moves have failed does a native app earn the question. By that point you'll know, not because the agency told you, but because you've watched your own people work and found a gap that genuinely is shaped like an app. Those projects, when they ship, are the good ones.
If you're in the meeting right now, the line to use is straightforward: “Before we sign, let's run an hour against what we already own.” The agency's response will tell you what kind of agency they are. The good ones will agree, because they want the work that actually pays. The other kind will hurry past it. Both responses are useful.