An afternoon with a mobile booking screen

A mobile screen is a useful size for an AI-assisted prototype: small enough to inspect, but large enough to expose layout, interaction, and accessibility problems. This walkthrough uses an appointment-booking screen built with Expo and React Native. The aim is a working local prototype, not a finished booking system.

§ Step 1: Write the screen contract

Before opening a coding assistant, describe one user task and the boundaries around it. For this example, the user chooses an appointment time and confirms a booking. Leave authentication, payments, and calendar synchronization outside the prototype.

Give the assistant a brief with observable requirements:

• Content: service name, provider, duration, price, date selector, available times, and a confirmation button.
• Behavior: selecting a time enables confirmation; confirming shows a local success state.
• Constraints: use mock data, respect safe areas, support large text, and make the screen scroll on small devices.
• Non-goals: no network requests, backend, or additional navigation.

Ask the assistant to list unresolved decisions before generating code. Settle details such as the initially selected date and the wording for unavailable appointments. This prevents plausible but unwanted product decisions from becoming implementation defaults.

§ Step 2: Connect the coding environment

Create an Expo project using the current Expo setup instructions, then launch the starter screen on a simulator or physical device. Confirm that the unchanged project runs before involving AI. That gives you a known working baseline.

Vana API provides one endpoint at https://api.vanaapi.com, with support for OpenAI-compatible requests, Anthropic Messages, and Gemini native protocols. It works with tools such as Claude Code, Codex, and Gemini CLI. Create a Vana API account, generate a key, and configure your chosen tool using its current provider instructions.

For an OpenAI-compatible client, configure the provider base URL and authentication through its supported settings. Check the current API documentation for the required path suffix and exact model identifier rather than deriving either from a display name. Claude Sonnet 5.5 is one option for this coding workflow. Keep the API key in your development environment, never in the mobile app bundle.

§ Step 3: Ask for the smallest runnable version

Give the assistant your screen contract and the relevant project files. Ask it to inspect the existing structure before editing. A useful instruction is: Implement this as one screen using existing dependencies. Use local state and mock appointment data. Do not add a backend or install packages without asking.

Request a short implementation plan, then let it make the changes. Prefer a few clear components over an elaborate design system: a service summary, a date selector, time-slot buttons, and a confirmation area are enough.

Run the result immediately. Check the terminal and device logs before judging the visual design. Resolve build errors and runtime warnings first, ideally one issue per follow-up request.

§ Step 4: Review the screen on a device

Inspect the rendered interface rather than relying on the assistant’s description. Take a screenshot and, if your tool supports image input, attach it with specific observations. Otherwise, describe the problem and include the relevant component.

Replace requests such as “make it cleaner” with measurable feedback: The confirmation button overlaps the last time slot on the smaller simulator. Keep the button inside the safe area and ensure every slot remains reachable by scrolling.

Review text hierarchy, spacing, contrast, and touch targets. Increase the device’s text size and try a long provider name. Ask for focused corrections without changing unrelated layout or behavior.

§ Step 5: Test the states, not just the screenshot

A convincing prototype needs more than its initial appearance. Walk through a short state checklist:

• No time is selected, and confirmation is disabled.
• A selected time has a clear visual and accessible state.
• A date with no availability shows an understandable message.
• Changing dates clears any stale time selection.
• Confirmation shows the chosen date and time, with a way to start again.

Ask the assistant to add appropriate accessibility labels and roles, then verify the flow with a screen reader. Mock confirmation should be clearly distinguished from a real reservation.

§ Step 6: Save a reviewable checkpoint

Finish with a screenshot, the working code, and a short note covering assumptions, missing integrations, and known issues. Commit the prototype before requesting broader changes.

Vana API bills by actual tokens without a monthly fee. Keep iterations focused by sharing relevant files and reporting one concrete problem at a time. The useful outcome is a screen someone can try, question, and revise before backend work begins.