When Should You Not Build an App?

“We want to build an app” sounds, to many founders, like a logical sentence. Mobile apps feel like proof that a product is serious. They have an icon. They show up in a store. They can be pushed and updated.

For most early products an app is not the right answer. It is the most expensive answer. To a problem that can first be tested more cheaply.

This article looks at when not to build an app, which alternatives learn faster, and which signals actually do make an app the right call.

App vs web app vs landing page

There are roughly three levels of technology in an early product. Each has its own cost, speed and learning rhythm.

A landing page. A static page that explains what you offer, asks for a sign-up or a conversation, and has no functionality. Buildable in days. Changes every time you learn something new. Useful for testing demand, not for delivering anything.

A mobile-friendly web app. A real application that works in a mobile browser. Customers can take action, enter data, pay. Buildable in weeks. One codebase for desktop and mobile. Updateable the same day you learn something new.

A native app. An iOS and Android app distributed through the app stores. Months to build. Two codebases. Review process on every update. Limited ability to change quickly.

The question is not “which one should I build?”. The question is “which level fits what I want to learn in this phase?”. For most early products that is a landing page followed by a mobile-friendly web app. Not a native app.

App stores

App stores are not neutral distribution channels. They have rules, percentages, review processes and their own opinion about what makes a good app. For an early startup that brings a number of obligations that are not always visible at the moment you choose an app.

A developer account per platform (€/year). Review time during which a release is frozen. A 15-30% commission on in-app payments. Rules about what is and is not allowed, that can change with every update. A rejection that can delay your launch by a week.

For products where the revenue model directly relies on in-app purchases, you accept those terms consciously. For products where the first months are mostly about learning, they are pure cost without direct benefit.

Maintenance

You update a mobile-friendly website and your users see the new version immediately. An app has to go through a release cycle, build, test, submit, wait for review, release, and your users still have to update afterwards.

That means an app always has two versions in circulation: the one you released yesterday and the one users have not updated yet. You always have to think about what older versions still support, whether a new feature is available in older apps, and how to communicate that an update is needed.

In an early phase you want to be able to change. Nothing forces you to change less than an installed base of old app versions.

Updates

Critical updates (for example, a security fix) are slower to distribute through an app than through a web app. A review can take hours, sometimes days. During that time you are stuck with the old version in production.

For products with direct financial or sensitive interaction, that time difference matters. For products where the first customers are mostly about feedback, it is frustrating.

Validation

The biggest reason not to build an app in an early phase: validation costs more cycles. You update a mobile-friendly web app, customers see the new version tomorrow. You update an app, customers see it in weeks, if they update at all.

Early products learn by running cycles. Every cycle you cannot close because you are stuck in a release process is a week of learning you cannot do. In a phase where you want to change something every week, an app is actually a brake.

User behaviour

For most early products, the question is not whether customers will return many times every day. The question is whether they will come once, complete their first action, and be motivated enough to come back a second time.

For that test you do not need an app. A link in an email, a QR code at a physical location, or a recommendation from a colleague, a mobile web version handles all of that. A user who wants to try something within 5 seconds would rather do that than install something.

When an app does become the right call

There are moments where a native app is the right call. The three most common:

• Hardware access a browser does not have. Background processing, significant local storage, BLE connections to physical devices, AR functionality, intensive camera integration. For some use cases there is no way around a native app.
• Frequent daily use by the same users. For products people open ten times a day, banking, ride-hailing, social, an app lowers the friction per use enough to justify the build.
• Demonstrated retention impact of native presence. Once you have established that your product works and you want to scale, an app store presence can help with discovery and retention. But not before you have established that.

In all of these cases, the decision rests on an already-working product and existing customers. The app is not the way to find out whether the product works. The app is an investment in a product already proven to work.

Why a mobile-friendly web version is often better first

For most early products: a mobile-friendly web version tests all your key assumptions, delivers all your key customer value, and costs a fraction of a native app.

What a web version usually does not do is force people to give your product a permanent place on their phone. That sounds like a disadvantage. For an early startup it is usually an advantage, you test whether people voluntarily come back, not whether they accept your icon next to their banking app.

Once you have established that customers voluntarily return, an app is a logical next step. Before then, an app is mostly an expensive way to find out what a mobile website would have told you cheaper.

Why a mobile website often beats an app goes deeper into that distinction.

---

Facing this decision?

Send me the context or book a free call. We will look at the most sensible next step before you commit time, money or focus.

Book a free call → · Email directly: hello@yourstartup.expert