Prove a phone can reach your API
https://patrickz.ai/learn/mobile-api-proof/

OUTCOME
Retire connectivity uncertainty before adding an AI feature.

YOU NEED
A coding agent, a development phone and a minimal client/API practice project. Use no personal or employer data.

1. 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.

2. Build step 1
Create a FastAPI `/healthcheck` endpoint.

3. Build step 2
Run the API in Docker.

4. Build step 3
Create an Expo screen with a “Test connection” button.

5. Build step 4
Test on a physical phone through a tunnel.

6. Build step 5
Add typed API responses and visible error states.

7. Build step 6
Add authentication and data storage.

8. Build step 7
Add AI only when a specific user decision requires it.

9. 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.

PROMPT
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.

EXAMPLE / 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
[ ] A real phone receives the expected response.
[ ] An unavailable API produces an understandable error.
[ ] No secret is bundled into the client.

IF IT FAILS
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.

MY RESULT / NEXT CHANGE