Back to Blog

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

Mohammad Orabi·Founder & CEO·7 min read

Every founder wants an iOS and Android app. It feels "real." It is what they use. It is what their users use.

For early-stage products, native apps are almost always the wrong choice.

That is not a theory. Some of the most successful software companies in the world waited years before building a mobile app. And they were already worth billions when they finally did.

The Companies That Waited

Linear launched as a web app in 2020. They did not ship a mobile app until September 2024, four and a half years later. By that point, over 15,000 companies (including OpenAI, Ramp, and CashApp) were already using it. They were generating over $100 million in annual revenue. The mobile app was a nice addition. It was not the foundation of the business.

GitHub launched in April 2008. Their first mobile app shipped in March 2020. That is twelve years. In the meantime, they became the standard for code hosting, grew to 40 million developers, and got acquired by Microsoft for $7.5 billion. CNBC ran the headline: "GitHub, now under Microsoft, finally releases an iOS app, 11 years after launch."

Figma launched its web-based design tool in 2016. As of today, it still has no mobile editing app. The mobile app only lets you view and comment on designs. Yet Figma hit a $12.5 billion valuation, has over 4 million users, and filed for IPO. All on the web.

Basecamp launched in 2004. Their first native iPhone app did not ship until 2013. Nine years. In the meantime, they built one of the most influential SaaS products of the 2000s, stayed profitable and bootstrapped, and proved that web apps were all you needed.

None of these companies needed a mobile app to reach millions of users or billions in valuation. The web was enough.

The Math That Should Stop You

A native app means building the same thing twice. Once for iOS, once for Android. If you also have a web app, that is three codebases. That is 2 to 3 times the cost and 2 to 3 times the timeline. Not just for the initial build, but for every feature, every bug fix, every update after that.

Then there is the App Store. Two-week review times. Rejected updates because of vague policy violations. A 30% cut of every transaction. Rules that change without warning.

For an early-stage startup with limited budget and time, that cost is devastating. Every dollar spent maintaining two native apps is a dollar not spent on product development, user research, or growth.

Most Apps Do Not Need to Be Apps

Unless you need push notifications, camera access, offline mode, or hardware sensors, a responsive web app does everything you need. Modern web technology supports home screen installation, background sync, and fast performance. Users can add it to their phone and it looks like a native app.

  • Service workers give you offline capability and push notifications.
  • Progressive Web Apps can be installed on home screens and launch in fullscreen.
  • Responsive design adapts to any screen size automatically.

Your users do not care if it is "native." They care if it solves their problem. They will use it in a browser if it works.

The Real Path

Build a web app. Make it responsive. Test your idea. Get users. Get revenue. Prove that people care about what you are building.

Then, once you have proven the concept and have real money coming in, consider native. But not before. You will know when the time is right because your users will ask for it. Not because you imagined they would want it, but because they actually tell you that a web app is not enough.

That is what Linear did. What GitHub did. What Figma is still doing. They focused on building a great product first, and the platform question answered itself later.

Before you invest in native apps, ask: is there a specific capability my users need that the web cannot provide? If the answer is no, you are spending money on a platform, not a product.

Native Is Not a Sign of Seriousness

Native apps are not a sign of a serious product. They are a sign of a product with proven demand and the budget to support multiple platforms. Get there first. Prove the value on the web. Then expand.

The best products are not the ones on the most platforms. They are the ones that solve the problem best on whatever platform they choose.

More from the blog

Have a project in mind?

We keep a couple of slots open for the right fit. Tell us about your idea and we will figure out the rest.

Upwork