A developer named Dan Q got told to install an app. His kid's performing arts school was headed to Disneyland, and the travel agency's itinerary, flight details, and hotel info were locked behind a 43MB download called Travelbound. So he did what most people can't: he intercepted the app's own network traffic, found the plain URL it was pulling from, and rebuilt the whole thing as a single web page of about 0.05MB. His version was faster, worked on any device, was printable and searchable, and dropped the tracking. The post climbed to the top of Hacker News this week with hundreds of comments, most of them some version of "yes, exactly."

Here is the part worth sitting with if you run a business. When he took the app apart, he found only two things it did that a web page couldn't have done. It reported tracking data tied to your Google account back to the developer, and it showed you advertisements for other trips the agency sells. That's it. Both are things a customer would never ask for and never pay for. Everything else the app "did" was display information that was already written in HTML and delivered over the web. The app was a worse way to read a document.

That story is a clean test, and it applies to far more businesses than travel agencies.

Why owners get talked into apps

Somewhere along the way, an app became a status symbol. It reads as serious. It reads as "we've arrived." A competitor launches one and now it feels like table stakes. Plenty of agencies are happy to encourage that feeling, because building an app is a bigger invoice than building a web page.

The trouble is that the app is usually solving the agency's business problem, not yours. Your problem is getting information or a service in front of a customer with as little friction as possible. An app adds friction at the worst possible moment. Before a customer can use it, they have to find it in a store, decide it's worth the storage, install it, grant permissions, and keep it updated. Every one of those steps sheds people. A web page asks for none of it. You send a link, they're in.

The costs nobody mentions in the pitch

Publishing an app isn't a one-time build. It's a standing obligation across two ecosystems that don't talk to each other.

Apple charges $99 a year for the Apple Developer Program, every year, forever, or your app disappears. Google's Play Console takes a one-time $25 registration fee. Those are just the entry tickets. Then you're maintaining two separate codebases or paying for a framework that papers over the difference, submitting to two review processes that can reject you for reasons that have nothing to do with your customers, and shipping updates that users have to actually install before they take effect. A bug fix on a web page is live the second you deploy it. A bug fix in an app is live whenever your slowest customer next opens their app store.

And after all that, you reach fewer people. An app on the App Store reaches iPhone owners who install it. The same content on a web page reaches anyone, on any phone, tablet, laptop, or library computer, the instant they click. The web page is the larger audience. This is the point people miss when they assume an app is the more "premium" reach. It's the narrower one.

When an app actually earns its place

None of this means apps are bad. Some jobs genuinely need one, and it's worth being honest about which.

An app earns its place when it has to work offline, the way a field-service checklist or a boarding pass does. It earns its place when it needs real access to device hardware, like a camera doing live barcode scanning, precise background GPS, or Bluetooth talking to equipment. It earns its place when the whole point is high-frequency re-engagement driven by notifications, the way a messaging or fitness product lives or dies on push. And it earns its place when the experience is heavily interactive in a way that needs native performance, like a game or a serious drawing tool.

Notice what those have in common. In every case, the app does something a web page structurally cannot. If you can't name that thing in one sentence, you probably don't have it.

There's also a middle path that has quietly gotten very good. A progressive web app is a website that can be installed to the home screen, work offline, and send push notifications, without ever touching an app store or its fees. For a lot of businesses that thought they needed an app, a PWA is the honest answer: most of the app-like feel, none of the app-store tax.

The test, in one line

If the thing you want to build mostly displays content, takes a booking, shows a menu, or lets someone check a status, it should be a web page. That's not a downgrade. A web page is easier to find, cheaper to maintain, reachable by more people, and usually more accessible to customers using assistive technology, which apps are notoriously bad at. It's also where your customers already are. Most of them are meeting your business on a phone screen through a browser long before they'd ever consider installing anything.

We build both at Pixelworx, and we'll tell you plainly which one your situation calls for. More often than owners expect, the right build is a fast, well-made web presence rather than an app, because the web page does the actual job and doesn't ask your customers to work for the privilege. The goal was never to own real estate on someone's home screen. It was to make the first thing a customer sees do its job, and that first impression rarely happens where owners think it does.

Before you sign off on an app, make someone say the one sentence: here is the thing this app does that a web page can't. If nobody can finish it, you already have your answer. If you want a second opinion before you commit the budget, we're happy to give you a straight one.