Insights · My Build Studio

You do not need an app store to have an app

What a progressive web app is in owner language, when the app stores are still worth it, and how one codebase can ship to the web, the phone, and the store.

3 minute read

When an owner says “we need an app,” they usually mean three things at once. Customers should be able to open it from their phone with one tap. It should work like software, not like a brochure. And it should feel like theirs, with their name on the icon. None of those three requires an app store. They require a progressive web app, and most businesses that ask for an app are better served by one.

What a progressive web app is

A progressive web app is a website built to behave like an installed application. It loads at a normal address, so anyone can reach it with a link. But it can also be added to a phone’s home screen with its own icon and name, open full screen without the browser bar, keep working when the connection drops, remember what the person was doing, and send notifications with permission. On current phones, an installed web app can look and feel like anything from the store.

The word “progressive” describes how it degrades. On an old browser it is still a working website. On a modern phone it is an app. Nothing is gated behind a download.

Why owners are usually better served by one

The first reason is friction. Asking a customer to visit a store, search, download, and sign in loses most of them before they see the first screen. A link in a text message opens instantly, and the option to install comes after they already see the value.

The second reason is control. A web app is yours. There is no review queue between you and a fix, no percentage owed on what you sell inside it, and no risk of being removed for a policy change you did not cause. When your staff needs a new field on a form, it can be live the same day, for everyone, with nothing to update.

The third reason is cost. One codebase, one deployment, one thing to maintain. The alternative is often three: a website, an iPhone app, and an Android app, each needing its own updates and its own specialist. For a small company, that is the difference between a tool that gets better every month and a tool that gets frozen because nobody has time to touch it.

When the stores are worth it anyway

There are honest cases for the stores. If your customers will search the store for your product by name, being absent looks like being fake. If your app needs deep access to the device, certain sensors, background processing, or payment features that only native code can reach, the store is the path. If you sell to large organizations that distribute software through managed devices, they may require a store listing. And some categories of app simply carry more trust when the icon came from a store.

None of those reasons means abandoning the web app. They mean adding a store presence on top of it.

One codebase, everywhere

This is the part that has changed in the last few years. A well built web app can be wrapped for the stores without a rewrite. The same code that runs at your address can be packaged as an Android listing and as an iPhone listing, with the small amount of native glue those platforms require. Fixes are made once. Features ship once. The store versions follow.

That is how My Build Studio approaches it. Build the web app first, make it installable and fast, and add the store wrappers only when a specific reason appears. The owner gets an app on day one, keeps ownership of it, and never pays for the same feature three times.

The question to ask

Instead of “do we need an app,” ask “what should a customer be able to do from their phone in two taps.” The answer to that question is a design brief. The delivery method follows, and it is almost always a link.

A question about this note?

Write to the studio that published it. Replies come from the founder.

Send an inquiry

Prefer email? hello@buildgrowforward.com
Response within two business days.