Plate 0.5 · Phase 0 — Ground Floor · 15 minutes
Website, web app, or native app?
The first four modules were knowledge. This one is judgment — the first time you're asked to decide something rather than learn something. It is also the question you will be asked more than any other, usually in these words: "Can you build me an app?"
Warm-up · from Module 0.4What's the one habit for opening a project in VS Code?
Open the folder, not the file (File → Open Folder). That's what switches on the file tree, project search and Live Preview.
Why the professional answers with a question
When someone says "app", they almost never mean a specific technology. They mean the thing on my phone that solves my problem. Four quite different things fit that description, they cost wildly different amounts, and choosing wrong is expensive in a way that isn't obvious for about six months.
So the professional response isn't "sure, $40,000". It's "tell me what people will actually do with it" — and then a recommendation with reasons attached. By the end of this module you can give that recommendation.
Four kinds of premises
Think about a business choosing where to trade.
Where a business could set up
- A poster in a window
- People read it, learn the hours and the prices, and walk on. Cheap, instantly changed, seen by everyone passing.
- A shop you walk into
- There's a counter, staff, a till, a record of what you bought. People come in and do things.
- A shop in a mall that also gives you a key
- Same shop — but you can let yourself in after hours, and they can ring you when your order's ready.
- Your own building on the landlord's street
- Total control of the inside. The landlord decides who's allowed on the street, takes a cut of every sale, and inspects your renovations before you may open.
What you would build
- A static website
- Pages of information: menu, portfolio, prices, contact. HTML and CSS. Phases 1–2 of this manual.
- A web app
- Something people use, in a browser: bookings, dashboards, Google Docs, Gmail. Adds JavaScript and usually a backend. Phases 3–7.
- A PWA — installable web app
- The same web app, installed to the home screen, working offline, able to notify. One extra layer on top of what you already built.
- A native app
- Downloaded from the App Store or Play Store. Swift, Kotlin, React Native or Flutter — a different craft, and not this manual.
Build the lightest thing that actually does the job, and move up a level only when a real requirement forces you to. Every level up costs more to build, more to change, and reaches fewer people. Nobody has ever regretted shipping something simple in three weeks; plenty of people have regretted a native app nobody installed.
Decide it yourself
Tick everything the thing genuinely has to do — not what would be nice, what it has to do. The recommendation updates as you go, and tells you which requirement pushed it up a level.
What does it actually need to do? Tick every need that applies. The answer follows the strongest group you reach.
| If the needs include... | Build | Why |
|---|---|---|
| Only reading: pages of information, rare updates by one person, found on Google and shared as a link | Static website | Hosted free, found by search engines, changed in minutes. Phases 1 and 2, plus Module 5.6. |
| Doing things: accounts, saved data, different views per person, payments | Web app | Code on a server and a database behind it. Phases 1 to 4 for the front, Phase 7 for the back. |
| Installed-app feel: works with a bad connection, opens from the home screen, notifies when closed | Installable web app (PWA) | A web app plus an offline layer and a home-screen icon. Push works on iPhone only after install. |
| The phone itself: Bluetooth, NFC or USB; background location; App Store listing; heavy 3D or AR | Native app | Only installed code can do these. A different craft and a bigger budget. |
The tick that leads to the hardest group wins. One native-only need makes the whole answer native.
Notice how few things force you all the way to native — and notice that all of them are about hardware and the operating system, never about how serious or ambitious the idea is. Figma, Google Docs, Google Sheets and Gmail are all web apps.
What each choice actually costs you
| Static site | Web app | PWA | Native app | |
|---|---|---|---|---|
| To get started | Days | Weeks | Weeks + a bit | Months, usually × 2 platforms |
| Found on Google | Yes | Yes | Yes | No — only in the store |
| Shareable as a link | Yes | Yes | Yes | Only a link to install it |
| To use it, people must… | Click | Click | Click, and optionally install | Find, download, install, open |
| Shipping a fix | Minutes | Minutes | Minutes | Days — store review |
| Store's cut of sales | None | None | None | 15–30% on digital goods and subscriptions; none on meals, rides or physical products |
| Works offline | No | No | Yes | Yes |
| Bluetooth, NFC, background location | No | No | Partly on Android, no on iOS | Yes |
That fourth row is the one people underestimate. Every step between "saw the link" and "using the thing" loses a large share of people. A link goes straight there. An install asks for a store visit, a download, a password and a permission dialog — before anyone has seen a single benefit.
On Android, installable web apps are genuinely close to native: install prompts, notifications, offline, even Bluetooth. On iPhone, Apple allows less. Web push notifications work — but only after the user has manually gone Share → Add to Home Screen, which Apple gives no prompt for, so far fewer people ever get there. There is no background sync, no Web Bluetooth or NFC, no background location, and no App Store listing. Promise a client "notifications like a real app" on iPhone and you will be having an uncomfortable conversation later. Say instead: notifications for the minority who install it.
Three real briefs
Read each one, decide out loud before you reveal the answer, and say two reasons. This is the assessment for this module, so don't skim it.
Almost everything here is reading — menu, photos, hours, address. That's a static site: fast, cheap, found on Google the moment someone searches "restaurant near me", and shareable in a Facebook post. The one interactive part is the reservation — and you don't build that yourself: you embed a booking widget from a service like OpenTable or Resy. Their servers hold the bookings; your static page just shows their form. (Contrast the gym below, which needs its own accounts and schedule — that's a web app.)
Two reasons to say out loud: the value is in being found, which favours the web; and nobody installs an app for a restaurant they visit twice a year.
The trap: agreeing to a native app because the owner's nephew said apps look professional. It would cost ten times more and be opened by almost nobody.
Client says: "We're a family diner in Asheville, North Carolina. We want people to see the menu and photos, know when we're open, and be able to reserve a table."
A static website, with one small booking feature.
Almost everything here is reading: menu, photos, hours, address. That suits a static site, which is fast, cheap and found on Google. The reservation comes from a booking widget by a service like OpenTable or Resy. Their servers hold the bookings.
Say out loud: the value is in being found, and nobody installs an app for a diner they visit twice a year. The trap: agreeing to a native app because someone said apps look professional.
Background location tracking — location reported while the app is closed and the phone is in a pocket — is the one thing the web genuinely cannot do on either platform. That forces native for the riders' side, and nothing else will do.
The dispatchers, though, sit at desks and need a map, a list and reports. That's a web app: no installs, works on any office machine, updated the moment you fix something.
The lesson: "which one" is sometimes the wrong question. Different users, different needs, different builds — sharing one backend.
Client says: "We run a courier company in Denver. We need to see where our forty riders are all day, and riders need to mark each delivery as done, even in areas with no signal."
Both. A native app for riders, a web app for the office.
Reporting location while the app is closed in a pocket is the one thing the web cannot do on either platform. That forces native for the riders. Dispatchers sit at desks and need a map, a list and reports, which is a web app.
The lesson: "which one" is sometimes the wrong question. Different users, different builds, one shared backend.
Booking means accounts and saved data, so it's a web app rather than a static site. The basement pushes it one level further: a PWA can cache the schedule so members still see it with no signal, and members who install it get a home-screen icon and — on Android reliably, on iPhone if they install it — reminders before class.
Two reasons: people use it repeatedly and briefly, which is exactly what an installed icon is for; and it must survive a bad connection, which only the offline layer gives you.
What you would not promise: reliable iPhone notifications for everyone. Only for those who install it.
Client says: "Our gym members should be able to check the class schedule and book a slot from their phone. The gym is in a basement where the signal is terrible."
A web app, built as a PWA.
Booking means accounts and saved data, so it is a web app. The basement adds the offline layer: a PWA can cache the schedule, and members who install it get a home-screen icon and class reminders.
Two reasons: people use it briefly and often, and it must survive a bad connection. Do not promise reliable iPhone notifications to everyone, only to people who install it.
What this means for your path
Everything in this manual builds static sites and web apps, and the PWA layer sits on top of what you'll already know. That covers the honest answer to the great majority of "can you build me an app?" conversations you will ever have.
And if a project genuinely needs native one day, you won't be starting over. React (Phase 6) is the same mental model as React Native; JavaScript and TypeScript come with you; the backend in Phase 7 is identical whether a browser or a phone app is talking to it. Nothing here is wasted.
Three things beginners get wrong
1. Assuming native means serious. It means a store listing, a review queue, a percentage of your revenue, and an install screen between you and every user. Those are costs, not credentials.
2. Assuming "web app" means small. Figma runs a full design tool in a tab. Google Sheets recalculates a hundred thousand cells in one. The browser stopped being the limitation a long time ago.
3. Calling a responsive website an app. A site that looks good on a phone is still a site. The line isn't the screen size — it's whether people do things that are remembered afterwards.
Words you now own
- static site
- Pages that are the same for everyone, served as files.
- dynamic site
- Pages built per request, so different people see different things.
- web app
- Software you use in a browser rather than content you read.
- SPA
- Single-page app: one page that rewrites itself instead of loading new pages. Module 6.8.
- PWA
- A web app that can be installed, works offline, and can notify.
- native app
- Built for one operating system and installed from its store.
- cross-platform
- One codebase producing both iOS and Android apps — React Native, Flutter.
- install friction
- Everyone lost at each step between hearing about it and using it.
Say it to a person, not to yourself.
Model answers to compare with
Why most people asking for an app need a web app — in three sentences
"An app from the store makes every customer find it, download it and install it before they see anything — and most won't bother for a business they use now and then. A web app is just a link: it works on every phone and computer, shows up on Google, and I can fix things in minutes instead of waiting for Apple to approve an update. You only need a real store app if it has to do something only the phone can, like tracking location in the background."
A worked example: a barbershop in Columbus, Ohio
Recommendation: a static website with an embedded booking widget (from a service like Square Appointments). Reason 1: customers mainly need hours, prices and location, and to be found on Google — that's reading. Reason 2: bookings are handled by the widget's own servers, so there's nothing to install and nothing to maintain.
Check your own answer
- Did you start from what people do with it, not from "apps look professional"?
- Did you pick the lightest option that does the job?
- If you said native, is it for a hardware or operating-system reason?
Six questions. Four correct to move on.
"Build the lightest thing that does the job. Reading is a website. Doing is a web app. Offline and installable is a PWA. Hardware and the operating system are the only real reasons to go native." That sentence is worth money in a client meeting.