Nobody Wants to Download Your App
A post titled iT woRKs BeTter in THe aPp hit the Hacker News front page with 628 points on August 28. Roughly half of users who see an install prompt never finish. Here is how to decide whether you need an app at all.
Why did a rant about a calendar app get 628 points?
On August 28, 2026, Terence Eden published a 500-word post about trying to subscribe to a calendar feed on his Android phone. He had the URL. He had a current Pixel running Android 17 with an updated Google Calendar app.
He could not do it. Google's own support page says you must use a desktop web browser to subscribe to a calendar, because you cannot do it in the Calendar app on Android, iPhone, or iPad.
So he opened calendar.google.com in desktop mode on his phone, added the feed, and watched it appear in the app.
The post hit the Hacker News front page with 628 points and 433 comments. That reaction is the interesting part. A tiny piece of missing functionality in one app produced hours of collective venting, because everyone has hit the same wall.
Eden's diagnosis is worth reading twice. Apps are hard to update. Every new feature needs testing across a thousand devices and then a slow rollout. The fix teams reach for is having the app pull functionality from a remote server. At which point, as he puts it, you have reinvented the web browser.
How many people actually install when you ask?
About half do not. Industry measurements through 2026 put the drop-off at roughly 50 percent of users who see a native install prompt and never complete the install.
Think about what that means for a first-time founder with no brand. You paid for the click. You paid for the landing page. Then you put a mandatory install between the visitor and the thing they came to do, and half of them leave before seeing your product work.
The counter-argument is real: users who do install are worth more. Retention and repeat engagement are better on native apps for loyal customers. Nobody serious disputes that.
But that argument is about your best customers, and you do not have those yet. Early on, your problem is not deepening engagement with people who already love you. It is getting anyone to experience the core value once. Install friction is a tax paid at exactly the wrong moment.
What do you actually need native for?
Short list, and it keeps getting shorter.
Background processing that must survive the browser being closed. Reliable push on iOS without an add-to-home-screen step. Deep hardware access, meaning Bluetooth peripherals, precise camera control, health data, and some file system work. Store presence when the store is itself your discovery channel, which is true for games and some consumer utilities. Payments where the platform requires you to use its billing.
That is close to it. Offline mode is solved on the web with service workers. Home screen icons are solved. Camera and location are solved. Even serial over Bluetooth is getting there in Chrome.
If none of the items on the short list describe your product, you are not choosing native for capability. You are choosing it because apps feel more like a real company, and that is not a product decision.
What is the sequence that usually works?
Ship the web version first. Make it fast on a mid-range Android phone on a bad connection, not on your laptop.
Instrument the moments that would only get better with native: a user who returns four times in a week, a user who wants notifications, a user who hits a hardware limit. Count those people.
When the count is big enough to fund the second codebase and the second release process, build the app for them specifically. Not a shrunken copy of your website. The thing your repeat users are trying to do.
This sequencing also protects you from the failure Eden is describing. The half-finished app exists because a team shipped a mobile presence before they knew which jobs mattered, then never went back. If you build native from measured behavior instead of ambition, you know what has to be complete on day one.
Mapping which features belong on which surface, and what each path actually costs to build and maintain, is the kind of thing that gets fuzzy in your head and clear on paper. A spreadsheet works. So does Notion, or a structured planning tool like Foundra that walks first-time founders through the tradeoffs section by section.
Your AI co-founder is ready when you are.
Foundra turns everything in this article into an actual plan. Validation, customers, pricing, launch. In one place, in your voice, in an afternoon.
Get started→$39/month. Cancel anytime.
What does a half-finished app cost you?
More than the build.
You now maintain two products. Every feature ships twice, gets tested twice, and breaks twice. For a three-person team that is not a doubling of work, it is closer to a tripling once you count release management and store review.
You also inherit a new class of user complaint. The web version and the app drift apart, users find the gap, and support tickets arrive that are really just "why does your product have two personalities."
And you take on the platform risk. Store review, policy changes, and enforcement actions now sit between you and your customers. Founders discovered this again this week when an open-source project was pulled from Google Play by an automated copyright notice with no evidence attached.
None of that is an argument against ever building an app. It is an argument against building one before you can afford to finish it.
Is the web catching up on install?
Slowly, and in a direction worth tracking.
Early attempts at web install were awkward. On Android, the beforeinstallprompt event only fires when the browser had already decided to offer installation, which makes it unreliable to build against. On iOS, adding a site to the home screen still means finding it in the share sheet, which most people never do.
That is changing. A newer Web Install API lets a site open an install dialog in response to a user action, like a button click, rather than waiting for the browser. In January 2026, representatives from Apple, Google, Microsoft, and Mozilla met to discuss how sites should be allowed to advertise installation from inside the page.
Do not build a strategy on a spec that is still moving. Do watch it, because the gap it closes is the exact one that pushes teams into native prematurely.
How should you present the choice to your users?
Stop interrupting people who are trying to use your product.
Interstitials that block content to push an install are a known conversion killer and have been penalized in mobile search for a decade. If you show a prompt, show it after a moment of success, not before.
Say what the app does that the web cannot. "Get notified when your order ships" earns an install. "Get the app for a better experience" does not, because users have learned it usually means a worse one.
And let people finish anything they start in the browser. The most reliable way to lose a customer is to promise the app is better, then punt them back to the web the moment they do something slightly unusual.
Key takeaways
About half of users who see a native install prompt never complete it. That is the tax you pay before anyone sees your product work.
Native is worth it for background work, reliable iOS push, real hardware access, store-driven discovery, and platform billing. Most early products need none of those.
Ship web first, measure who is asking for more, then build native for those people specifically.
A half-finished app costs more than no app, because it splits your team and trains users to distrust the thing you keep asking them to install.
If you do ship an app, finish the jobs it claims to do. That is the whole complaint behind a front-page post with 433 comments.
Frequently asked questions
Should my first version be a mobile app or a website?
A website, in almost every case. It is faster to ship, faster to change, and it removes the install step between a stranger and your product. Build native once you can name the specific capability you need and the specific users who need it.
Does a progressive web app count as an app?
Functionally, often yes. Service workers give you offline support, a manifest gives you a home screen icon, and push works on Android and on iOS after add-to-home-screen. What you do not get is store discovery or platform billing.
Will investors expect an app?
Some will ask. The better answer is usage data from your web product, not a second codebase built to look serious. Founders who can explain why they have not built an app yet tend to sound sharper than founders who built one by default.
How much does maintaining a native app really cost?
Budget for double the feature work plus release overhead: store review, staged rollouts, device testing, and supporting old versions users refuse to update. For a small team the ongoing cost usually exceeds the initial build within a year.
What if my competitors all have apps?
Check their reviews before you copy them. A common pattern is a thin app with mediocre ratings shipped for the same reason you are considering one. Being the product that works properly in a browser is a real position.
When is it clearly time to build the app?
When a measurable group of returning users is repeatedly blocked by something only native can do, and when you can staff the second codebase without slowing the first one down.
Sources
- iT woRKs BeTter in THe aPp (Terence Eden's Blog, Aug 28, 2026)
- Hacker News discussion, 628 points and 433 comments
- Subscribe to someone's calendar, Google Calendar Help
- Window: beforeinstallprompt event, MDN Web Docs
- Web App install API discussion, W3C public-webapps list, January 2026
- Mobile-friendly web pages using app banners, Google Search Central
- Using Service Workers, MDN Web Docs
You just read the theory. Ready to build the thing?
Foundra is your AI co-founder. It turns an idea into a validated business plan, a go-to-market, and your first 10 customers. In an afternoon, not a semester.
$39/month. Cancel anytime. Works in 20 languages.