Apps fail long before launch, usually in the questions nobody asked. We've shipped our own, including Recovery Toolbox, our mobile app, and we've watched plenty of would-be founders skip straight to screen designs. The screens are the fun part. The answers below are the part that decides whether the screens ever matter. Before you spend a dollar on development, write these down.
The market questions
1. Who is this for, specifically?
Not a demographic; a person with a moment. Who is standing where, annoyed by what, when they reach for your app? If you can't describe that moment, you can't design the first screen, and you certainly can't market it. The narrower the person, the sharper the product; you can widen later, from strength.
2. What does it replace?
Every app displaces something: a spreadsheet, a phone call, a competitor, doing nothing at all. Doing nothing is the most common rival and the hardest to beat, because it costs your user zero effort. Name the incumbent and be honest about why anyone would go through the trouble of switching.
3. Why an app instead of a website?
An app has to earn its home-screen slot. If the job is occasional lookups, a fast mobile site wins and skips the app-store gatekeepers entirely. Apps justify themselves with frequency, offline use, notifications, or device hardware. Which of those is genuinely yours? If none, you may be building the expensive version of the wrong thing.
4. How will people find it?
The app stores are not a discovery strategy; they're a warehouse. Decide before you build how people will hear about this: search, an existing audience, partnerships, a website that ranks. In our experience the app succeeds or starves on distribution, and distribution decided after launch is a rescue mission.
The money questions
5. What does it cost to run, not just build?
The build is the down payment. Hosting, app-store review churn, OS updates, support email: an app is a living product with recurring bills. Talk to anyone who has shipped one: the surprise is never the invoice for version one, it's the drumbeat afterward. Budget year two before you commit to month one.
6. How does it make money, and when?
Paid up front, subscription, ads, or a funnel into something you sell elsewhere: each model changes the design itself, from onboarding to which features sit behind the gate. A business model chosen after launch is a redesign, not a setting you flip.
7. What does success look like at twelve months?
Pick the number now (installs, retained users, revenue, leads) and pick the number that would tell you to stop. Founders who define failure in advance quit bad ideas cheaply and redirect the budget. The ones who don't fund the sunk cost for years.
The build questions
8. What is the smallest version that proves the idea?
Not the smallest version you'd be proud of, but the smallest one a stranger would actually use. Every feature past that point is a bet placed before you've seen any cards. Ship the wedge, watch real behavior, and let usage argue for the rest of the roadmap. It will argue for different things than you expect.
9. Who maintains it after launch?
Someone must own crash reports, OS-update breakage, and user reviews from day one. If the answer is "the agency, maybe," you don't have a maintenance plan; you have a future emergency with your name on it. Decide who answers when the app breaks on a Saturday.
10. What happens if it works?
Success has costs too: support volume, infrastructure, feature demands from your loudest users, and the operational load of a real customer base. Sketch the version of the plan where things go right. It's the least-asked question on this list and the most expensive one to skip.
Ten honest answers will save you more money than any framework choice ever will. And if you'd like a second set of eyes before you commit, this is exactly where our product and app development work starts, before a single screen gets drawn.