Fig. 18 — Web applications
Web development
Anything reached through a browser — a product, a portal, a dashboard. No install, one address, and every visitor on a different machine than the one it was built on.
The browser is the constraint
A web product runs on hardware you did not choose, over a connection you cannot predict, on a screen of unknown size. That is the whole difficulty, and it is why a build that looks right on the machine it was written on means very little.
- Tested at real widths, from a phone up, not only at the size of a developer's monitor
- Performance budgeted from the start — fonts, images and third-party scripts are where pages get heavy
- Keyboard, contrast and screen-reader behaviour built in, because retrofitting access is far more expensive
- Server-rendered where it matters, so pages are visible to search engines and fast on first paint
Visible to search, not just to users
A web product nobody can find is a private tool with a public address. Titles, descriptions, canonical URLs, a sitemap and a structure a crawler can walk are part of the build rather than a later project — and they are cheap while the pages are still being written.
Where this ends and something else begins
If the product needs to live on a phone home screen, use the camera or work with no signal, it wants a mobile app instead. If it is a subscription product with tenants and billing, that machinery is its own body of work. And if you are testing whether anyone wants the thing at all, a first version answers that faster and cheaper than a full build.