Don't Build a Mobile App (Build This Instead)

Founders often treat an iOS and Android app as proof that the product is real. An icon on a phone feels more substantial than a browser tab.

But the platform should follow the job. It should not be the job.

Do Not Buy Two Kitchens Before You Know the Menu

Imagine opening a restaurant and building two separate kitchens before learning which meal customers will order. Every recipe change, safety check, and equipment repair must now be handled twice.

Separate native applications create a similar obligation. A feature may need platform-specific design, implementation, testing, release review, and maintenance. That cost can be justified. It should buy something the product genuinely needs.

“Our users are on phones” is not enough. Almost every user is on a phone. The useful question is what they need to do there.

Start With the User’s Real Context

A responsive web product may be enough when users need to open a link, complete a short workflow, review information, or use the product across desktop and mobile without device-specific behavior.

Native becomes more compelling when the product depends on capabilities or conditions such as:

• reliable background activity or time-sensitive notifications;
• deep use of the camera, location, Bluetooth, or other device hardware;
• substantial offline work with later synchronization;
• frequent use where platform integration materially improves the workflow; or
• distribution or trust requirements tied to an app marketplace.

The Web Is Not Automatically the Cheap Version

A careless responsive site that barely works on a phone is not a sensible alternative to native. The core journey still needs clear interaction, appropriate performance, accessible controls, and testing on the devices people actually use.

Likewise, modern web capabilities do not erase every platform difference. Installation, notifications, background behavior, and browser support vary. Decide from the required behavior and current platform evidence, not from a slogan about progressive web apps.

Build the Smallest Platform Strategy That Proves Value

If the first product is a scheduling tool used mainly from shared links, a responsive web flow may validate booking without maintaining two native releases. If later evidence shows that field workers need offline access and device scanning all day, a native application now solves a demonstrated constraint.

That sequence reduces scope without lowering the quality of what users are asked to judge.

Native is not a badge of seriousness. It is an investment in a particular user context. Make sure you have that context before you pay for the investment.