So you’re wondering whether you should start with a mobile app, a website, or both. First off, discard the myth that it costs the same to do all in one. Supporting multiple platforms does not have the same cost of supporting one, regardless of the latest and greatest technology.
Let’s start with the fallacy that deploying to multiple platforms using Apache Cordova/Phonegap cuts your development time to the cost of one platform. Different platforms may have different web view renderers, and bugs may exist on one platform and not the other. You have to keep a constant watch on each platform, and if you don’t quickly address bugs on one platform, be ready to pay the price in poor reviews. Moreover, fixing platform-dependent bugs in hybrid apps can take longer than native apps due to requiring some kind of workaround.
Using hybrid technologies, optimistically you can cut the initial build time to 75%, but when you factor in the lifetime cost, the total cost of maintaining your app becomes much pricier than most entrepreneurs are prepared for. In almost every single scenario we’ve seen, it makes more sense to start with a single platform (choose one out of web / iOS / Android) and validate your prototype first with a very soft launch and finish debugging before moving on.
But how do you decide between a mobile app or a website? The remaining questions are meant to help you answer this.
1. Is a core feature based on native functionality?
There are certain features within mobile apps offer that are such huge advantages over web that they tip the scales in favor of starting with a mobile app. A few that come to mind are geolocation using the phone’s GPS, push notifications, real-time tracking, offline data storage, or integration with native tools like Google Fit / S Health / HealthKit.
Yes it is possible to use HTML5 to tap into some of these via a browser, but you might actually end up spending more time getting it to work well in HTML5 than native. Remember that the advantage of developing a browser-accessible website is about functioning on a lot of different devices and browsers, and not competing with mobile apps on native functionality.
2. Does creating a mobile app take advantage of a market opportunity?
I’ve seen some websites out there that would make perfect mobile apps, except the years go by and they still don’t have one. This may be a perfect opportunity to take some version of an idea that’s already been validated, do it better, and bring it to the app store. (This begs a reminder that someone out there has already thought of your brilliant idea — winning is about execution.)
For example, maybe there’s a location-based RV parking sharing app that hasn’t hit mobile because it’s not a sexy industry. This market would be begging for a mobile app since it’s the perfect marriage of under-the-radar and the audience being entirely mobile since they’re always on the go. Creating a mobile app here would make much more sense than a website.
3. Is pay-to-use rather than recurring revenue your primary monetization?
If you’re convinced that your primary revenue will come from users paying once to unlock your app, this form of monetization is commonplace for mobile apps yet hasn’t flourished for websites. On the other hand, the web has an advantage when it comes to recurring revenue, where Apple and Android both take 30% of your revenue for in-app purchases and subscriptions. (Some argue that the free visibility of being in the app store gives you visibility that makes up for the 30% loss, but your app stands a fat chance of getting featured in the app store without App Store Optimization, which basically means you still have to pay for marketing help.)
If you answered no to all 3, then start with a website due to lower development costs.
Just try to build the website with companion mobile apps in mind by starting with an API backend and separate frontend like Angular or React. Doing it this way is not substantially more expensive than say doing it entirely in Ruby on Rails, but this way, if and when you decide to build a mobile app, you can reuse the same API, and maybe even some of the frontend code as well.