Lesson 6 of 11 ·10 min read

Your Path to a First App

A realistic path for a Python developer on Windows, at zero cost until there's a reason to spend.

After this lesson you can explain

Why the right first app is a small client for an API you already run, and how the four-sentence screen test keeps it scoped.
Why Expo fits a Python developer on a Windows machine, and how EAS cloud builds solve the no-Mac iOS problem.
Where the cost line sits: what stays at €0 forever, and which shipping decision triggers the first fee.

1. Pick the right first project

The classic mistake is choosing an app idea that is secretly a startup. A good first app is a client for an API you already understand, with two to four screens. The rule: the backend should be boring to you, so the entire learning budget goes to the one new thing (the client side).

Best candidate: a phone front-end for an API you already run. If you have an API of your own deployed, the backend already exists, the data is something you actually look at, and the app is pure client work. Read-only first; editing is a later stage.
Alternatives from the book's world: a weather app (OpenWeather), a Spotify "now playing" screen, a Guardian headlines reader. All are APIs the book already covers.

Scope test for a first app: you can describe every screen in one sentence each, and there are at most four sentences. "A list screen, a detail screen, a settings screen" is a first app. Anything with accounts for other people is not.

2. The stack: Expo (React Native), Flutter as runner-up

For this specific situation (a Python background, some vanilla JavaScript, a Windows machine, zero budget), Expo wins on three practical grounds:

Language head start. It is JavaScript/TypeScript. Not fluent territory, but familiar if you have written any browser or serverless JavaScript; Dart would be a from-zero language.
The Windows/iOS problem is solved for you. No framework can build an iOS app locally on Windows; Apple's toolchain requires a Mac. Expo's cloud build service (EAS) compiles iOS builds on their Macs, so an eventual iOS version does not require buying one. Flutter on Windows has no equivalent built into its standard workflow.
The ten-minute feedback loop. Install the Expo Go app on the phone, run one command on the PC, and the app appears on the phone over WiFi, hot-reloading as you type. No Android Studio, no emulator, no SDK setup for the entire early learning phase.

Terminal

npx create-expo-app my-first-app
cd my-first-app
npx expo start        # scan the QR code with Expo Go -> app is on your phone

When Flutter would be the better pick instead: if the JS ecosystem's churn is intolerable, if you want one strongly-typed batteries-included framework, or if the app's UI is heavily custom-drawn. It is a fine tool; it is just a heavier on-ramp from here.

The mental-model bridge: a React component is a function that returns UI from state, and re-runs whenever state changes. That is a Jinja/Nunjucks template that re-renders itself. useState is the template context; changing it is what triggers the re-render. Most of React's apparent strangeness dissolves once seen through that lens.

3. Toolchain checklist

Tool	Status	Cost
Node.js + npm	Likely already installed; free from nodejs.org if not	€0
VS Code	Free download; most Python developers already have it	€0
Expo Go (phone app)	Install from Play Store	€0
Expo account (for EAS builds)	Sign up when needed, not before	€0 (free tier: limited monthly cloud builds)
Android Studio emulator	Optional, only for testing without the phone	€0 (large download)
Google Play developer account	Only if publishing publicly	$25 one-time
Apple developer account + iOS distribution	Only if shipping iOS	$99/year

The zero-cost line: everything needed to build, learn, and run the app on your own phone is €0. The first money is spent only if an app earns a public release, and that decision can be made months after the app exists and is in daily use.

4. The learning path, stage by stage

Estimates assume evenings-and-weekends pace and deliberately build the real project from day 3 rather than finishing a course first. Tutorial purgatory is the main schedule risk, not the code.

Stage 1: a weekend

JS refresher + the four React ideas

Modern JS syntax (arrow functions, destructuring, async/await; skim, it is close to Python), then exactly four React concepts: components, props, useState, useEffect. Ignore the rest of the ecosystem (Redux, contexts, memoisation); a small app never needs it.

You'll be Googling: "useState vs useEffect", "map over array in JSX".

Stage 2: week 1–2

First screens, hard-coded data

Core RN building blocks: View (a div), Text, FlatList (scrolling list), Pressable. Navigation via Expo Router: files in an app/ folder become screens, the same file-based routing instinct as static site generators. Get your API's data on screen from a hard-coded JS object first; make it look right before making it live.

You'll be Googling: "FlatList keyExtractor", "Expo Router pass params between screens", flexbox layout (the same flexbox as CSS).

Stage 3: week 2–3

Talk to the real API

Swap the hard-coded object for fetch(). This is requests.get() with a different name: same verbs, headers, JSON, status codes. The genuinely new part is UI state around the request: a loading spinner, an error message, an empty state. Three states per screen, always.

This is where the book knowledge pays off directly. Most beginners hit their first wall here; an API author will not.

You'll be Googling: "useEffect fetch on mount", "pull to refresh FlatList".

Stage 4: week 3–4

Storage, auth, polish

Cache the last response (AsyncStorage) so the app opens instantly and works offline: the local-storage layer from How Apps Actually Work, in miniature.
Auth if the API needs it: a bearer token in SecureStore (the Keychain/Keystore wrapper), attached to every request; that is steps 7–8 of the login-flow lesson in miniature. For a personal app, a long-lived token issued by your own backend is fine; skip the full OAuth dance.
Polish: app icon, splash screen, dark mode. All Expo config, not code.

Stage 5: when it works

Put it on your phone permanently

Expo Go is for development. For a permanent install, run one EAS command to produce an APK, download it on the phone, and install directly (sideloading; Android allows this, and it is not jailbreaking). No store, no review, no fee. This is the correct final state for a personal-use app.

Terminal

eas build --platform android --profile preview   # produces an installable .apk

5. The backend: already solved

The half of app development that is server-side (endpoints, auth, JSON design, error handling) is the half this book already covers. For an API you already have deployed, the app may need nothing new at all, or at most one read-only endpoint exposing the data as JSON (with a token check). This asymmetry is the whole reason the estimate below is weeks and not months.

6. Shipping decisions, if it ever goes public

Goal	Route	Cost / friction
Personal use	Sideloaded APK (stage 5)	€0; reinstall manually on updates
A few friends / testers	EAS internal distribution, or the same APK shared directly	€0
Public Android release	Google Play	$25 one-time; new personal accounts must run a closed test with 12+ testers first; store review on every release
Public iOS release	App Store via EAS cloud builds	$99/year; review is stricter than Google's; no Mac needed thanks to EAS

7. Pitfalls specific to this path

Pitfall	Avoidance
Tutorial purgatory: three courses deep, nothing built	Start the real project on day 3; learn each concept when the project demands it
Scope creep: the personal app grows accounts, sync, sharing	The four-sentence screen test from §1; new ideas go in a "v2 someday" note
Dependency sprawl: installing a package for every small thing	A first app needs almost nothing beyond Expo's built-ins; every dependency is future upgrade pain (the RN tax from the frameworks lesson)
Fighting the styling system	RN styling is flexbox; the CSS knowledge transfers, but there is no cascade: styles are per-component objects. Accept it early
Testing only on the dev machine's network	Phones roam; test on mobile data early, and test with the phone's font size turned up (large accessibility fonts break layouts that looked fine at defaults)
Letting the app crowd out work that pays	A first app is a learning project with no revenue attached; schedule it as learning, not as a project anything is waiting on

8. Honest time estimate

A useful three-screen personal app, at side-project pace: three to six weeks, front-loaded: most of the friction is in stages 1–2 where everything is unfamiliar, and the last two stages usually go faster than expected because they are mostly API work in different clothes.

The frame that ties the lessons so far together: an app is an API client, its login is token auth, its notifications are two API integrations joined at a token, and the framework is the least durable layer of the stack. Which means a Python API developer starting mobile is not starting from zero; they are starting from the harder half already done, learning only the rendering layer on top.

Check your understanding

What makes an app idea a good first project, and what does the four-sentence screen test rule out?
Why can't a Windows machine build an iOS app locally, and how does EAS route around that?
Where on this path is the first money actually spent, and what decision triggers it?

Sources and further reading

Reviewed 4 August 2026.