VanaAPI

← Writing

A first appointment screen on a phone

Daily workEN2026-10-29

A mobile screen is a useful first project with an AI coding assistant. It is small enough to describe clearly, but concrete enough to test with your hands. You can see whether the text fits, whether a button is easy to reach, and whether the next step makes sense.

For this first prototype, imagine an appointment screen for a local repair shop. It needs a service name, a date, a few available times, and a booking button. The goal is not to build a booking system. It is to find out whether someone can understand and use this one screen.

§ Start with a short brief

Before opening a coding tool, write down who the screen is for and what they should accomplish. Describe the content and behavior before choosing colors or fonts. This gives the assistant something more useful than “make a modern app.”

A starting prompt could be:

Build a mobile appointment screen for someone booking a bicycle repair. Show the service name, price, selected date, and four available time slots. Let the user select one time. Keep the booking button disabled until a time is selected. Use sample data only. After booking, show a confirmation message without sending any data.

This brief includes a purpose, visible content, and a simple interaction. It also sets a boundary: no real reservations, accounts, or payments.

§ Choose somewhere to run it

If you already have a mobile project, ask the assistant to follow its existing framework and styling. If you are starting from nothing, React Native with Expo is one possible route. React Native builds mobile interfaces using JavaScript or TypeScript; Expo provides tools for running and previewing those projects.

Ask the assistant to explain the setup before changing files. A useful instruction is: Assume I am a beginner. Tell me which software I need, give me the setup steps in order, and explain how to open the result on my phone.

Use a coding assistant that can work with project files, or copy its suggested changes into your editor. Keep the first request limited to one screen. Navigation, notifications, and a database can wait.

§ Connect the assistant, not the prototype

Vana API can supply the model behind a compatible coding tool. It provides one endpoint at https://api.vanaapi.com, supporting the OpenAI-compatible interface as well as Anthropic Messages and Gemini native protocols. It works with tools including Claude Code, Codex, and Gemini CLI.

Create a Vana API account when you are ready to connect a compatible tool. Follow the tool’s configuration instructions for the endpoint, API key, and model selection. A model such as Claude Sonnet 5.5 can help draft the screen and revise the code. Usage is billed per real token, with no monthly fee.

The prototype itself does not need an AI connection. Here, AI helps you build the interface. Do not put your Vana API key in mobile application code, screenshots, or shared project files.

§ Review one change at a time

Once the screen runs, resist asking for a complete redesign immediately. First check whether it matches the brief. Can you select a time? Does the button become available? Does the confirmation reflect your selection?

Then ask for a focused revision:

The time slots feel crowded on a narrow phone. Increase the spacing and make the selected slot clearly different without relying on color alone. Keep the existing booking behavior.

Small requests are easier to inspect and undo. Save a working version before each substantial change, using a local copy or version control.

§ Test the screen as a person would

  • Open it on a real phone and check whether you can read the text comfortably.
  • Try a longer service name and a larger system text size.
  • Check that important content stays clear of the camera cutout and bottom system controls.
  • Tap the booking button twice and check the result.
  • Ask someone else to book a time without explaining the screen.

Write down where they hesitate. That observation is the prototype’s main output. You can then revise the screen, keep the useful parts, or discard the idea before investing in a full application.