patrickz
Before you start
A coding agent, a physical phone that can reach your computer (same network or a temporary tunnel), and the stack the steps name: Python with FastAPI, Docker, and Node.js with Expo. Another API framework or mobile client works if you adapt the steps. Use no personal or employer data.
Why this lesson exists
The archived mobile-to-API proof began with one physical phone reaching a health endpoint, before any authentication, storage or AI.
Do the exercise
Set your boundary
Keep the first version to one health endpoint and one phone screen with a Test connection button that shows the response or a readable error. Add authentication, data and AI only after a physical phone passes that test.
Create a health endpoint
Create a FastAPI /healthcheck endpoint that returns harmless data.
Run the API in Docker
Run the API in Docker, then call the health endpoint from your computer before trying the phone.
Add a Test connection screen
Create an Expo screen with a “Test connection” button.
Test on a physical phone
Test on a physical phone, over the same network or a temporary tunnel. Close the tunnel afterwards.
Type responses and show errors
Add typed API responses and visible error states, including when the API is stopped.
Next sessions, not today
- Authentication and storage Add authentication and data storage.
- AI for one decision Add AI only when a specific user decision requires it.
A prompt to adapt
Replace the bracketed parts with your own details.
Help me prove a physical phone can reach my API, in a new practice folder, with FastAPI, Docker and Expo. Keep the first version to one health endpoint and one phone screen with a Test connection button that shows the response or a readable error. No authentication, data storage or AI yet, and no secrets in the client. List the setup commands before changing any files. Then work in five checkpoints and, after each, tell me how to check it: 1. A FastAPI health endpoint. 2. The API running in Docker. 3. An Expo screen with a Test connection button. 4. A test on the physical phone over [the same network or a temporary tunnel], never localhost. 5. Typed API responses and a visible error when the API is stopped. My computer’s development address: [IP address or tunnel URL].
Once it runs, paste your code and ask:
Review this phone-to-API proof. Check that the development address is configurable rather than hard-coded to localhost, the stopped-API error is readable on the phone, responses are typed on both sides, no secret or tunnel URL is bundled into the client, and any temporary tunnel is closed after testing. List each gap and the test that catches it.
Run this experiment
Create a harmless health endpoint. Call it from the physical phone, then stop the API and verify a useful error. Restore the service and retry.
Check your result
Use evidence from your output. A confident explanation from the AI is not enough.
If it isn’t working
localhost on a phone means the phone, not your development computer. Use an explicitly configured development address and close any temporary public tunnel after testing.
Optional. Progress stays in this browser.
Where this came from
Adapted from an archived project architecture write-up. Its repository is private; this lesson uses only a general practice scenario and requires no private source code. Project coverage.
Prepared September 2026. Tools and interfaces change; use current official setup instructions. Session lengths are estimates.