Before you build a mobile MVP, answer these five questions

You have an app idea. Maybe you have sketches, a few reference apps, and a launch date in mind. It’s tempting to start by choosing Flutter or Kotlin and asking how much the whole thing will cost.

I’d start a little earlier. Before estimating screens, I want to understand the one thing a person should be able to accomplish with the first release.

The questions below are a practical starting point for that conversation. They don’t replace discovery, but they make it much easier to discuss what you’re actually buying.

What should the user finish?

“An app for booking services” leaves a lot open. “A customer can choose an available appointment and receive confirmation” gives us a journey to examine.

What happens before the booking? Who controls availability? What counts as confirmation? Those questions expose the work behind the screen.

For a first release, write down the journey in ordinary language. If it takes three paragraphs to explain, try separating the core journey from the optional features. You can keep the bigger vision without putting all of it into the first delivery.

Which uncertainty should we test first?

Imagine an app that connects to a custom device. The welcome screen might be straightforward; reliable communication with the device might be the part we understand least.

In that situation, I’d propose a small integration milestone before polishing every screen. We agree on the device, the action, and what counts as a successful test. Then we learn whether the proposed approach is workable.

The same question applies to a payment provider, an unfamiliar API, or a difficult import format: which assumption could change the estimate most?

What happens when the normal path fails?

A customer taps Confirm and the connection drops. Should the app retry, show a pending state, or ask them to try again? What if the request succeeded but the response never arrived?

You don’t need to specify every possible error before development begins. You do need to agree on the important states in the main journey. “Loading,” “empty,” “failed,” and “completed” deserve attention alongside the ideal screenshot.

Permissions are another example. Android’s guidance recommends asking in context and handling denial gracefully. A permission request should fit the feature the person is trying to use. Android permission guidance

An example milestone brief

For the hypothetical appointment app, a first milestone brief could say:

• Included: Select a service, view slots supplied by the test API, request a booking, and display its confirmed or failed result.
• Required from the client: Service definitions, API access, test accounts, and agreed confirmation wording.
• Outside this milestone: Payments, recurring appointments, and the staff scheduling interface.
• Acceptance: Demonstrate a successful booking, an unavailable slot, and a request interrupted by connectivity loss.

This is an example of scope wording, not a price estimate. It exposes an important dependency: someone must provide the availability system. If that system doesn’t exist, backend work needs its own scope rather than being assumed to come with the screens.

Who owns the things around the app?

The app may depend on designs, API documentation, test accounts, store accounts, and a backend. Someone needs to provide or build each of those.

Before agreeing to a delivery date, I’d write down the dependencies and their owners. A short list is enough: who supplies the API, who reviews the design, who answers product questions, and who controls release access.

This also makes handover clearer. Ask for an explicit agreement covering source code, setup instructions, configuration, and the support period. Don’t leave those details until the final invoice.

How will we decide the milestone is done?

“Looks good” is useful feedback, but a weak acceptance criterion.

For the booking example, a milestone could require a customer to select a valid slot, receive the expected confirmation, and see a clear result when no slots remain. The exact tests should match the agreed scope and environment.

A smaller milestone with a clear outcome is easier to review than a large collection of partially connected screens. It also gives you a better basis for deciding what to build next.

If you’re preparing a brief, bring the main journey, the known dependencies, and the questions you haven’t answered yet. Those are enough to start a useful engineering discussion. The framework decision can follow; I’ve covered that separately in Java, Kotlin, Flutter, and KMP.