Web, Native, or Both: How I Decide Where a New Product Lives

One of the first real decisions on any new product is where it lives. Is it a website you open in a browser, an app you install from a store, or both?

People usually treat this as a technology question. For me it almost never is. I've built on Ionic for a decade, and with Capacitor the same codebase can ship to the web, iOS, and Android. The code isn't the hard part. The hard part is everything around the code: who decides when it ships, how people find it, how it takes money, and what happens when a rule changes.

Three of my products landed in three different places. Here's why.

Redinfinite: Web Only

Redinfinite is an infinite Reddit scroller. The current version is a progressive web app, a SvelteKit site on Cloudflare Pages that you can add to your home screen. There's no store listing.

That was deliberate. Redinfinite is a client for someone else's platform, and the first version died in 2023 when Reddit's API pricing changed. When I rebuilt it this year, I wanted as few gatekeepers as possible between the product and the people using it. A web app has one: the platform it reads from. An app store version adds a second, with its own review process and its own opinions about third-party clients.

It also fits how the product works. There's no login, no account, and no payment to process. Settings live in your browser. When I push a fix, everyone has it the next time they open the page. For a small, free tool, that's hard to beat.

What I gave up: discoverability. Nobody stumbles onto a PWA while browsing a store. Redinfinite has to be found through search, links, and word of mouth. For this product, that's a fair trade.

Game Night: In the Stores

Game Night is a party game app, built with Angular, Ionic, and Capacitor, shipped to iOS and Android.

The deciding factor was how people look for it. When someone wants a party game for tonight, they open the app store on their phone and search. They don't usually go to a search engine looking for a website. If Game Night weren't in the stores, it wouldn't exist for most of the people who've installed it.

Store presence also matters for trust. Ratings, reviews, and install counts do a lot of convincing for a game you're about to play with a room full of friends. A website can say it's good. A store listing with real reviews shows it.

What I gave up: speed. Every release goes through a store pipeline. Fixes that would take a minute on the web take a build, a submission, and sometimes a wait. I've automated most of that pipeline, but it's still slower than pushing to a website, and a review can hold up a release I thought was ready.

AI Recaps: Both

AI Recaps summarizes YouTube videos and podcasts. It runs on the web and as native iOS and Android apps, all from shared Ionic code.

It ended up in both places because people use it in both places. Some want a recap of a long video while they're at their desk. Others want it on their phone between things. Picking one would have meant telling half the users to go somewhere else.

Payments made "both" more work than it sounds. On the web, AI Recaps takes payments through Stripe. In the native apps, subscriptions go through the stores' in-app purchase systems, which I manage with RevenueCat. That's two billing paths, two sets of rules, and the job of keeping one person's subscription consistent no matter where they bought it. Shared front-end code doesn't make that problem go away.

What I gave up: simplicity. AI Recaps is the most moving parts I've ever had in one product. Some days I'd trade a lot for one platform. But it's the right shape for how people use it.

The Questions I Actually Ask

When a new idea shows up, these are the questions that decide where it goes:

1. How will people find it? If the answer is "searching an app store," it needs to be in one. If it's search engines, links, or an existing community, the web works.
2. Does it take money, and how? A free tool can skip the whole question. A paid product on native means in-app purchases and the stores' cut. On the web, I control billing.
3. Whose rules does it have to live under? Every store and platform is someone else's policy. The more of them a product depends on, the more ways it can break without me changing a line of code.
4. How fast do I need to ship fixes? If a product changes often, or breaks when something upstream changes, the web's instant updates are worth a lot.
5. Does it need the device? Push notifications, background work, deep hardware access. These push toward native mobile, though the web keeps closing the gap.

Usually two or three of these point the same way and the decision makes itself.

Why "Both" Isn't the Default

Since my stack can target everything, people ask why I don't ship every product everywhere. The answer is that each platform is its own product to maintain. Each one has its own release process, its own review rules, its own billing, its own support questions, and its own way of breaking. The code is shared. The work isn't.

For a one-person studio, that work is the real budget. I'd rather ship one product in the right place than three versions of it that I can't keep up with.

If you're weighing the same call for your own product, I can help you work through it.