Editor’s Note: Semil Shah works on product for Swell, is a TechCrunch columnist, and an investor. He blogs at Haywire, and you can follow him on Twitter at @semil.
For the past few months, my weekly column here has been focused on some aspect of “mobile.” There’s no denying the scope of the platform shift, user volume, and consumer attention. Yet, for startups, being “mobile-first” in today’s market is a dicey proposition given the harsh realities of distribution and the fact consumers are bombarded with too many indistinguishable choices. Taken together, it begs the question: “For new startups today, is mobile-first the right choice?”
In this post, I’ll share some conditions under which being mobile-first today either isn’t necessary or puts a new startup at a disadvantage. The idea here is to play the devil’s advocate for a day, to gently push back against the strong mobile tailwinds and reexamine some reasons why new startups can or should begin their work on the web, even if they end up with a mobile presence eventually. With that spirit in mind, and in no particular order, here’s what I came up with:
Some markets make mobile-first simply unnecessary or unviable. Consider products aimed at people in large corporations who work on desktops or laptops all day long. Yes, this segment is not growing as fast as mobile is, but then again, nothing is growing as fast as mobile. Specifically, products targeting users in larger enterprises, or where security in information technology (especially in mobile) is a concern, or where the user is required to create content through heavy input (like writing or number-crunching) provide examples where mobile-first just doesn’t work. Applications and solutions targeted at these types of customers are likely better off to start web-first and then grow from this point of origin.
Relatively speaking, easier to recruit web developers versus mobile developers. The market for experienced, quality iOS and Android developers and designers is extremely tight. If and when these folks do their next thing, it will likely be as a founder or close to formation of a new company. In the absence of a mobile developer on the team, focusing on the web can make it slightly easier to find and recruit engineers.
Faster cycles for iterations, testing, and moving toward product-market fit. With the team of web engineers ready to go, building for the web, relative to mobile, is a more sane path in many regards. Onboarding, an area where many mobile users drop out of the funnel, can be easier on the web, which impacts retention through emails captured at sign-in. Initial features can be layered in as the stack is built on the back-end, and the team and users can run more precise tests to see what does and doesn’t work. As we all know on mobile, this level of freedom in development is virtually unattainable, as cycles for development, user testing, and feedback loops are considerably longer, and therefore more expensive.
The web provides a strong foundation to build a brand and harness virality. If a web team is fortunate enough to pick up some traction and move closer to that elusive goal of product-market fit, being on the web confers some advantages over mobile. First, web users are often logged into other sites with their data or graph information, which makes sharing and inviting a bit easier. More people using the product on the web also increases the likelihood that more people will be exposed to the brand and learn to identify what it is. This type of awareness can be invaluable when it comes time to extend a presence to mobile, because those audiences can be encouraged over time to download a mobile app rather than discovering it through random channels.
Mobile can be thought of as an extension, not the foundation. When it comes time for a website or web software product to extend its reach into mobile, it can drive current users to its application with a more direct message and call to action. To do this, of course, the team will need mobile engineers and designers who can not only work with the current team, but can articulate a vision for how users on mobile interact with the service. The hope is, by this point, a team is ready to extend and can show some evidence of success, some money in their bank account, and some demand from users to provide a mobile touchpoint.
There are many more reasons why new companies should seriously think twice about mobile-first. Perhaps a more reasonable way is “mobile-eventually.” Of course, there are some products and services which are truly, inherently mobile in nature — like Uber — that need to either start on mobile or extend rapidly after quick web testing. But for the majority of mobile applications continuously flooding the market as consumers drown in a sea of choices, going “mobile-first” has been and remains a seductive, risky approach. There will always be a few elite teams who architect larger systems on more than one platform from the beginning, and those folks either have the money and/or experience to play a longer game. This luxury isn’t distributed widely. Instead, the majority of teams are faced with more fundamental, existential questions, and while mobile is “shiny” today and will be for a very long time, getting to the handset doesn’t necessarily mean one has to start there.