Before you start
A coding agent, a development phone and a minimal client/API practice project. Use no personal or employer data.
Why this lesson exists
This lab adapts the “Prove a phone can reach your API” project write-up into a practice build. The time is an estimated first session, not a promise to finish a production system. Use the public repository as a reference when available; the exercise can be built with original sample content.
Do the exercise
Define the practice version
The archived mobile-to-API proof of concept teaches an order of operations: connectivity, clear errors, identity and data before model integration. This is a general architecture exercise, not access to private source.
Build step 1
Create a FastAPI `/healthcheck` endpoint.
Build step 2
Run the API in Docker.
Build step 3
Create an Expo screen with a “Test connection” button.
Build step 4
Test on a physical phone through a tunnel.
Build step 5
Add typed API responses and visible error states.
Build step 6
Add authentication and data storage.
Build step 7
Add AI only when a specific user decision requires it.
Run the 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.
A prompt to adapt
Replace the bracketed parts with your own practice details.
Work in a disposable practice project. Explain any setup requirements before changing files. Build one small step at a time and show how I can check it. Design a proof-of-concept plan for an Expo mobile app and FastAPI backend. The first milestone is a physical phone successfully calling a containerized health endpoint. Include file structure, commands, CORS, tunnel testing, error states, and a definition of done. Review this proposed AI fuel assistant. Identify the actual user decision, data required, non-AI baseline, safety risks, cost controls, evaluation dataset, and criteria that would justify adding an LLM. My first-version boundary: The archived mobile-to-API proof of concept teaches an order of operations: connectivity, clear errors, identity and data before model integration. This is a general architecture exercise, not access to private source.
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.
- A real phone receives the expected response.
- An unavailable API produces an understandable error.
- No secret is bundled into the client.
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.