10 Questions to Ask Before Building an App (A Founder's Checklist)

The cheapest time to change your app is before anyone has written a line of code. A question answered in a planning call costs you an hour. The same question answered after launch can cost you a rewrite.

When founders come to me with an idea, I don’t start with frameworks or screens. I start with questions. Some of them have obvious answers. Some of them stop the conversation for a few days, and those are the valuable ones.

Here are the ten I ask on almost every project. You don’t need perfect answers to all of them. You need to know which ones you can’t answer yet.

1. Who exactly is this for, and what’s the one job it does for them?

“Small business owners” is a market, not a user. “The owner of a two-person auto repair shop who keeps customer records in a notebook and loses track of who owes what” is a user. You can design for that person.

Then the harder part: what is the one job the app does for them? Not the ten things it could do. The one thing that, if it works, makes them open the app again tomorrow.

If you can’t say it in one sentence, the app will try to do everything, and version one will take twice as long and do each thing half as well. Most of the planning work in scoping an MVP comes down to protecting that one job.

2. Which platforms do you actually need on day one?

iPhone, Android, web, tablet, or some mix? The answer depends on your users, not on what’s fashionable.

A consumer app in some markets is mostly Android. A tool for US contractors might be mostly iPhone. An internal tool might be used on a desktop browser at a front desk. Cross-platform frameworks like Flutter make shipping to both mobile platforms much cheaper than building twice, but every platform you add still means more testing, more store listings and more devices to support.

Also ask about tablets early. “It should work on iPad too” is easy to plan for and annoying to retrofit.

3. What must the app connect to?

Integrations are where hidden complexity lives. Make a list of every outside system the app needs to talk to:

• Payments (one-off, subscriptions or payouts to other people)
• Maps and location
• Calendars, email or SMS
• An existing website, database or CRM
• Accounting tools, booking systems, hardware

For each one, the question is: does it have a usable API, and does that API do what we need? Sometimes the answer is “yes, easily.” Sometimes it’s “only on the enterprise plan,” and it’s much better to learn that now.

4. Who manages the content and the users?

Almost every app needs someone behind the scenes. Someone adds products, approves new users, answers support requests, issues refunds, updates the FAQ or bans the spammer.

Ask yourself: when something needs to change, who changes it, and how? If the answer is “I’ll just ask the developer,” that’s expensive and slow. If the answer is “an admin panel,” that panel is a real piece of software that needs to be designed and built. It’s often missing from the first brief, which is why I wrote a whole post on building an admin dashboard for your mobile app.

Related: will several people use the same account with different permissions? Owners, staff, customers? Every extra role adds screens and rules.

5. What data will you collect, and what are the rules around it?

Personal information, location, health details, payment data, photos of people, anything involving kids: each of these comes with legal and store requirements.

You don’t need to be a lawyer, but you should know:

• What data you collect and why you need it
• Where it’s stored and who can see it
• Whether users can export or delete it (Apple and Google both require in-app account deletion when an app supports account creation)
• Which laws apply to your users, depending on where they live

Collect the minimum you need. Every field you store is something you have to protect.

6. How will the app make money?

“We’ll figure out monetization later” is a fine answer for some products. It’s a bad answer if the business depends on subscriptions that need to be designed into the app from the start.

The model changes what gets built. Subscriptions sold inside the app usually have to go through Apple’s and Google’s in-app purchase systems, with their rules and fees. Selling physical goods or services usually doesn’t. Ads change the layout and the privacy disclosures. A marketplace that pays out to sellers needs onboarding, payouts and dispute handling.

Knowing the model early avoids building a free app and then bolting on a paywall that doesn’t fit.

7. Does it need to work without internet?

Think about where your users actually are. A delivery driver in a rural area, a technician in a basement, a traveler on a plane, a worker in a warehouse with one bar of signal.

If the answer is “they mostly have a connection, and it’s fine to show an error when they don’t,” great. That’s simpler. If users need to keep working offline and sync later, that’s a significant architecture decision, and it’s much easier to make on day one than in month six.

8. Is the budget realistic for the timeline and scope?

This is the uncomfortable question, so I ask it directly. Budget, timeline and scope are linked. You can usually fix two of them; the third has to flex.

A useful exercise: list your features in priority order and draw a line where your budget runs out. Everything below the line is phase two. If the line falls above your one job from question 1, the plan needs to change before anything is built.

I explain how I turn a feature list into numbers in how I estimate a mobile app project. The short version is that you should expect a range, not a single figure, and be suspicious of anyone who promises everything for any price.

9. Who will maintain it after launch?

Apps aren’t finished at launch. Every year brings new iOS and Android versions, new store requirements and package updates. Users find bugs. Servers need patching. Certificates expire.

Before you build, decide:

• Who fixes bugs and handles updates after launch?
• Who owns the developer accounts, the code repository and the cloud accounts? (It should be you, the founder, with developers invited in.)
• Is there budget set aside for ongoing work and service costs?

An app with no maintenance plan slowly breaks. Not dramatically, just one store warning and one failed login at a time.

10. What does success look like 90 days after launch?

Pick something you can measure. Not “lots of downloads,” but something like: a certain number of shops using it weekly, a certain share of trial users converting, a specific workflow completed without support calls.

This question shapes everything above it. It tells us which features matter for version one, what analytics to add before launch (not after) and how to judge whether the next phase should go deeper on the same thing or change direction.

It also gives everyone the same finish line. Without it, “is the app working?” turns into a debate of opinions.

What if you can’t answer some of these?

That’s normal. Most founders have strong answers to three or four of these and educated guesses for the rest. The point isn’t to have a perfect plan. It’s to find the unknowns early, while they’re cheap.

When the important answers are fuzzy, a short discovery phase helps: a few focused sessions to work through the questions, check the risky integrations and write down a scope everyone agrees on. You come out with a plan you can take to any developer.

Takeaways

• Define one specific user and the one job the app does for them.
• Choose platforms based on where your users are, and decide on tablets early.
• List every integration and admin need up front; these hide most of the complexity.
• Know your data rules and monetization model before design starts.
• Be honest about offline needs, budget trade-offs and who maintains the app after launch.
• Agree on a measurable 90-day success goal so everyone aims at the same target.

If you’re working through these for your own idea and want someone to think them through with you, get in touch. Happy to start with the questions.