How to turn a client brief into a mobile app prototype
Turn a client brief into a mobile app prototype with a copyable AppX prompt, a practical test checklist, and a focused client-feedback workflow.
AppX team ·
To turn a client brief into a mobile app prototype, choose one workflow, describe its screen and behavior, and test the result before adding more features. In AppX, you can use that brief to generate an Expo and React Native starting point, then refine it through chat.
The first review should answer a concrete question: can the intended user complete the main task? Here is a practical workflow for independent developers and agencies, using an illustrative water-tracker brief.
1. Turn the client's paragraph into a testable scope
Suppose a client sends this:
We need an app that helps people drink more water. It should feel calm and be easy to use.
There are several products hiding in that sentence. A habit coach, a reminder service, and a daily counter would need different screens and data. For a first review, choose the smallest interaction that helps the client decide what they want.
Write down these five details:
- User: someone recording water during the day.
- Main action: record one glass of water.
- Screen: today's count, daily target, progress, Add a glass, and Reset.
- Expected result: adding a glass updates the count and progress together.
- Scope boundary: one screen with local interaction; accounts, payments, reminders, and a backend can wait.
That is enough to explain what the prototype should demonstrate. It also gives you a way to judge the generated result. For a broader prompt-writing checklist, read how to describe your app to AI.
2. Give AppX a prompt with observable behavior
Use the following example as a starting point. It is an illustrative prompt, not a report of a completed client project.
Create a one-screen mobile water tracker for someone recording their daily drinks.
Show today's date, a glass count starting at zero, and progress toward eight glasses.
Add a button labelled "Add a glass" that increases the count by one and updates the progress.
Add a separate Reset action that returns the count and progress to zero.
Use a calm blue palette, readable text, and comfortable touch targets.
Keep this first prototype focused on local interaction.
Do not add login, payments, reminders, a backend, or extra screens.
The behavior is more useful than a long list of adjectives. “Calm blue” gives visual direction. “Increase the count by one and update the progress” tells you what to test.
Paste your adapted brief into AppX's app description field. Submitting the brief carries it into the builder after sign-in. If AppX asks you to clarify the scope, answer with the screen and behavior you chose above.
3. Test the workflow before showing it to the client
Once a preview is available, use it as a testable first version. A rendered screen does not establish that its buttons, state, or edge cases work.
For this water tracker, run a short acceptance check:
- Confirm that the initial count and progress agree.
- Tap Add a glass twice. The count should read two and the progress should reflect two of eight glasses.
- Tap Reset. Both values should return to zero.
- Reach the daily target and observe what happens on the next tap. Decide with the client whether the counter should continue while the progress stays full.
- Check the layout at phone size: read every label, tap the controls, and look for clipped content.
Follow the project's available phone-preview instructions when you need to check device behavior. AppX's guide to Expo Go previews explains the approach. Preview availability and compatibility should be checked for the specific project.
Agree separately on whether progress should survive closing the app or reset on a new day. The example prompt does not establish those requirements. If something fails, fix it or label it clearly before the client review.
4. Give the client a task, then ask for feedback
Start with a task: “Record two glasses, then reset the count.” Watch where the client hesitates. That tells you more about the workflow than asking whether the screen looks nice.
Then ask:
- Is the main action obvious without an explanation?
- Does the result show the information you expected?
- What is missing from this workflow?
- What can wait until a later version?
Separate a visual preference from a new feature. A larger button changes the current screen. Reminders introduce scheduling, permissions, and additional behavior. Both can be valid requests, but they have different implications for the next phase.
5. Turn one piece of feedback into a specific edit
Keep each follow-up focused enough to verify. For example:
Make Add a glass the most prominent action on the existing screen.
Move Reset farther away from it to reduce accidental taps.
Keep the current counter behavior, daily target, and one-screen scope.
After the edit, repeat the same acceptance check. Confirm that the visual change has not broken the count or Reset behavior. Record what the client accepted and what remains unresolved.
The approved direction should leave you with a short list: the workflow to keep, the next changes to make, and the questions that need engineering work.
What happens after the prototype is approved?
Use the agreed direction to scope the next phase. Review data persistence, authentication, permissions, integrations, accessibility, failure states, and real-device behavior where the product needs them.
An Expo Go preview and an app-store release are separate steps. Store delivery also needs a suitable build, configuration, testing, and submission work. Expo's app-store build guide describes that distinction.
AppX generates an Expo and React Native project. If you plan to continue outside AppX, check the current source-code ownership information and plan details, then review the source ZIP download before agreeing on a client handoff.
Bring one real client paragraph to AppX, choose the main workflow, and define what a successful first review should show.