The App That Shouldn’t Exist

Travelbound is a mobile app that exists for one purpose: delivering a school trip itinerary. Dates, hotel details, coach times, destination information — the kind of static, read-only content that has lived comfortably on webpages since 1993. When parents at one performing arts school were told to download the Travelbound app to access travel arrangements for their children’s Disneyland trip, one developer did the math and found it didn’t add up.

A school trip itinerary is a formatted document. It does not require push notifications, hardware sensor access, or a persistent process running on your phone. A URL handles it. A PDF handles it. A shared Google Doc handles it. What a mandatory native app download handles, it turns out, is something else entirely.

The Travelbound app does two things a simple webpage would not do. It ties usage to your Google Account and sends tracking data back to the developers. It also serves advertisements — rebranded internally as “inspirations” — inside what users reasonably expect to be a functional travel tool. Neither of these is a feature from the user’s perspective. Both are extraction mechanisms dressed up as convenience.

This is the pattern behind a growing class of apps-that-should-be-websites: mobile applications with no meaningful interactive functionality, no offline capability that justifies installation, and no user benefit that a responsive web page couldn’t replicate in a fraction of the storage footprint. Users who comply take on the full cost — device storage consumed, app permissions granted, a third-party ecosystem trusted — while the developer captures behavioral data and advertising inventory.

The friction is the point. An app install creates a persistent data relationship. A webpage visit, especially one without a login wall, does not. Forcing a native app download for content that requires no native app is a UX decision made entirely in the developer’s interest, not the user’s. Calling it an “app” rather than a tracking and advertising product is the first misdirection. Requiring parents to install it for school trip access is the second.

What Coverage Usually Misses: This Is a Design Choice, Not a Technical Necessity

The conversation around app fatigue almost always stops at consumer frustration — too many apps, too much storage, too many passwords. What that framing conveniently skips is the question of why organisations choose to build native apps for content that static web delivery would handle without breaking a sweat.

The answer is not technical. Mobile browsers have supported responsive design, offline caching, geolocation, and rich media for years. Progressive web apps can send push notifications, work without an internet connection, and load on any device without an app store in the middle. The capability gap that supposedly justifies a mandatory install closed a long time ago.

What actually drives the decision is incentive alignment — and none of those incentives point toward the user. When a travel itinerary lives inside a native app rather than a URL, the publisher gains persistent access to a slot on your home screen, the ability to serve push notifications whenever they choose, and the data collection infrastructure to tie your behaviour to a persistent identity linked to your Google or Apple account. The Travelbound app, which one developer was required to install simply to view a school trip schedule for a Disneyland performance, illustrates this exactly. The app delivered two pieces of functionality beyond what a webpage would offer: it reported tracking data tied to Google accounts back to developers, and it served advertisements dressed up as “inspirations.” Neither feature benefits the person reading the itinerary.

This is not a design failure. It is a design choice, made deliberately, in favour of the publisher’s monetisation and data strategy over the user’s time and privacy. Calling it anything else — a technical requirement, an enhanced experience, a platform limitation — is a misdirection. The mobile web is not inadequate. It is simply less profitable to hand users something they can access, close, and walk away from without leaving a tracking footprint behind. Mandatory app installs for content-only experiences are a mechanism for converting a one-time transaction into an ongoing data relationship. Users pay the cost. Organisations collect the dividend.

The Fix: Converting the App to a Webpage

Rather than accept the friction, the developer did what most users can’t: he built the alternative himself. After being told to install the Travelbound app to access a school trip itinerary for a Disneyland performance, he reverse-engineered the app’s content and rebuilt it as a standard webpage. Same information. No download. No account creation. No permission requests.

The result made the original product look embarrassing. The webpage was smaller and faster, loaded without installation, and handed users their travel details without demanding anything in return. Every step the app required — downloading from a store, signing in with a Google account, accepting data permissions — disappeared. What remained was the actual content: itinerary, travel arrangements, accommodation details. Presented as a document, the way the web was designed to work.

This is where the rebuild becomes a damning piece of evidence. The Travelbound app offered nothing the webpage didn’t, except the two features the developer explicitly called anti-features: tracking data tied to your Google account sent back to the developers, and advertisements dressed up as “inspirations.” Strip those out and the app has no functional advantage over a basic HTML page. The app wasn’t a better product. It was a data collection mechanism with a trip planner bolted on.

The satisfaction of building a cleaner alternative is real, but it exposes an uncomfortable gap. This kind of pushback — reverse-engineering a bloated mobile app, replicating its core functionality as a lightweight web document — requires technical literacy that the vast majority of users simply don’t have. Most people handed a QR code pointing to an app store download don’t have the option to opt out and build something better. They install the app, hand over their data, and see the ads. The developer who can write the fix is rare. Everyone else is stuck with the version designed to extract value from them.

That asymmetry is the point. App-first delivery isn’t just an inconvenience for non-technical users — it’s a structural lock-in that only technical users can escape.

The Broader Pattern: App Stores as Gatekeepers

Every time an organisation routes you through the App Store or Google Play to access a travel itinerary or event schedule, it hands Apple or Google something valuable: a verified user identity, behavioural data, and another hook into a third-party service’s distribution chain. The app download is not a neutral technical choice. It is a toll booth, and the platform operators collect on both ends — from users through data harvesting and from developers through store fees and policy compliance.

The Travelbound case makes the economics visible. The app’s two distinguishing features over a simple webpage — Google Account tracking and an ad feed dressed up as “inspirations” — exist to extract value from users, not to serve them. That extraction happens because the app store model creates the infrastructure for it. A webpage with a URL serves content. An app with platform dependencies serves multiple masters simultaneously.

Organisations that don’t have those extraction motives still default to native apps for a different reason: app store presence reads as legitimacy. Having a listing in the App Store signals that a product passed some review process, carries a version number, and sits alongside recognisable brand names. For marketing departments, that perception of modernity outweighs any cost-benefit analysis of what users actually need to access.

Progressive Web Apps exist specifically to collapse this false choice. A PWA can work offline, send push notifications, install to a home screen, and load fast on any device — all without touching Apple or Google’s distribution infrastructure. The technology has been production-ready for years. The reason PWAs remain underdeployed is straightforward: bypassing the app store also bypasses the platform’s incentive to promote your product. Apple in particular has historically throttled PWA capabilities on iOS, limiting features that work fine in Chrome on Android. That asymmetry is not accidental.

The result is a web ecosystem where native mobile apps proliferate not because they serve users better, but because the distribution and monetisation incentives for every party except the user point toward the app store. Users pay with storage space, privacy permissions, and attention. The platforms profit. The organisations get a marketing asset. The webpage that would have done the job in three seconds never gets built.

What This Means for Everyday Users

Every app installed on your phone is a small contract you didn’t fully read. It can request access to your location, contacts, camera, and storage — permissions that a webpage simply cannot demand. When a school trip organiser forces you to download an app just to see a travel itinerary, those permissions exist to serve the app’s business model, not your convenience. The Travelbound app, which one developer was told to install for a children’s performing arts trip to Disneyland, exists to do two things a webpage cannot: track users via their Google Account and serve them advertisements dressed up as “inspirations.” That is the entire value proposition — for the company, not the user.

Multiply that dynamic across every venue ticketing system, every local gym, every parent-teacher platform, and every corporate event tool that demands a dedicated install, and you get a slow, cumulative erosion of the open web. The browser was designed to give users access to information without surrendering their device. Mandatory app ecosystems reverse that principle entirely. Each install is another foothold for a third-party data pipeline operating quietly in the background.

The burden falls hardest on people with older devices, limited storage, or restricted data plans. A webpage loads and disappears. An app stays, updates itself, and keeps running. For users who don’t scrutinise app permissions — which is most users — the privacy cost is invisible until it isn’t.

The practical counter-move is straightforward: ask the organisation why a webpage isn’t sufficient. Push back when a school, venue, or service provider frames an app download as mandatory. In most cases, the functionality involved — schedules, maps, itineraries, booking confirmations — translates directly to a mobile-optimised webpage with zero additional software required. When organisations can’t produce a genuine technical reason for requiring a native app, the real answer is almost always data collection or advertising revenue.

The open web remains a powerful standard. Users who treat unnecessary app installs with the same scepticism they’d apply to an unsolicited email attachment will protect their own privacy and, collectively, push back against the quiet normalisation of apps-as-gatekeepers.