Before you build an app, answer these 7 questions.

Someone on your board said it. A donor suggested it. A competitor has one.
However it arrived, the idea is now on the table: we should have an app.

Maybe you should. But app ideas almost always arrive oversized — carrying
accounts, notifications, chat, and a dashboard before anyone has proven users
want the core thing. And every unvalidated feature costs three times: to build,
to maintain, and to cut later. These seven questions are the filter we run in
every strategy sprint. They’ll either right-size your idea or save you the
entire budget.

1. Can a browser already do this?

Modern web apps handle payments, cameras, location, offline caching, and
home-screen installation. If your honest answer to “what does the app do that
a great mobile site can’t?” is push notifications alone, you’re considering a
five-figure project for a feature email might cover. The browser test
eliminates more app projects than any other question — it’s how
one of our clients funded three
languages of content with the budget an app proposal would have burned.

2. Will people use this weekly?

Apps earn their home-screen slot through frequency. A tool used monthly or
seasonally gets deleted in the next storage cleanup — and the median app loses
most of its users within days of install. Weekly-or-better use cases justify
apps. Anything rarer usually argues for the web, where there’s nothing to delete.

3. What is the ONE thing it must do?

Not the feature list — the single verb. “Let members register for events.”
“Let patients message the clinic.” If you can’t name one verb that delivers most
of the value, the idea isn’t ready to scope. If you can, you’ve just defined
your MVP, and everything else is a later phase that real usage will confirm
or kill.

4. Who is asking for this — you or your users?

“An app would be great” from a board meeting is a different signal than
“I wish I could do X on my phone” from twenty members. Before building, find
five real users and ask what they actually struggle to do today. If their
answers don’t mention your app’s purpose, you’ve learned something worth
five figures.

5. Can you afford the second year?

The build price is the entry fee, not the cost. iOS and Android update
annually, stores change their rules, libraries deprecate. A realistic budget
holds 15–25% of the build cost per year for maintenance. If that number
isn’t survivable, the app isn’t either — better to know before version 1.0.

6. Will your audience pay the install tax?

Every install is a small transaction: store search, download, permissions,
maybe an account. Audiences pay it for things they use constantly. For a
once-a-quarter interaction, each step loses people — and a link they can tap
from a text or bulletin outruns an app they have to install.

7. What’s the smallest version that proves it?

Not the smallest version you’d be proud of — the smallest that tests the
core verb with real users. Sometimes that’s a focused MVP. Sometimes it’s a
web flow you ship in three weeks to see if anyone uses it. The goal of version
one isn’t to impress; it’s to learn cheaply.

Scoring it honestly

If your idea cleared all seven, you likely have a real app — build the
focused version and skip the bloat. If it stumbled on the browser test or the
frequency test, congratulations: you just saved tens of thousands of dollars,
and a strategy sprint can put that
conclusion in writing with user flows and a scoped roadmap — whichever way the
evidence points.