8 good reasons not to build a mobile application
Building a mobile application rather than a mobile web service never sparks hard questions or good conversations in many startups and project organisations.
It’s a safe bet. We laugh. It’s sexy!
We launched Stuff officially in January. As a web service. Which have prompted the same question from people over and over again:
Why haven’t you launched as an application?
We did not have endless discussions and meetings on choosing technology platform for Stuff. It was pretty straightforward. There was no doubt on the founder team that a platform for sending invitations to private and public events required a web service. Not a mobile application.
Having had all sorts of conversations over the past weeks with organisers and guests, friends, digital product developers and people from the startup community it has become even more apparent to us, that we are on the right technology path for several reasons.
Some fundamental reasons which (apparently) requires repetition. And other reasons which are just downplayed or forgotten too often. Which is sad, impact taken into consideration.
So here are my 8 really good reasons to not building a mobile application.
8 reasons you should also consider when building digital services and products.
Shortening your funnels
Looking into a conversion funnel for any digital platform is self-torture. Most numbers are descending and approaching 0 sooner or later.
Adding an additional step — “Download in App Store” — is what nightmares are made of.
Asking people to download an application before having provided any specific value will set you back 20 to 50% in potential customer base — only because of the inconvenience of downloading an app.
10 years after the popularisation of mobile applications, too many companies are still convinced we will download a sexy application for simple tasks like receiving a quote or placing an order.
Immediate interaction
Separating your communication and messaging on, e.g. value propositions from your actual service and interactions make sense on outdoor and TV advertising where it is the only option.
However, separating the two on digital platforms makes very little sense if any.
Why not give potential customers immediate access to try your service? To see how it works. So they can check themselves if written communication matches the actual use of the service.
At Stuff, we have taken it one step further allowing customers to create an invitation before forcing them to create a profile. To show as many potential users as possible how simple it is to use our service.
Faster feedback loops
Structuring feedback loops are essential for new ventures.
Feedback from customers is one thing — and I have argued that emails are the best feedback channel for that.
Getting immediate feedback to specific views and functionality in your service from team members, co-workers and friends is another thing. But equally important.
If you can distribute a direct link and point to specific functionality, it will spark much faster and better feedback. Instead of asking people to upgrade to the newest (development) version of an application and navigate via burger menu to the 2nd view after blah blah, you will experience more substantial amounts of feedback on a direct link to a web service.
Trying to onboard a new potential business partner on your service?
Send them a direct link to their personalised web page while you are on the phone. It is much easier and convincing instead of asking them to download an application and search for their company name.
Simple interactions between people
Stuff is all about simple interactions between people on the frontend — just like many other services.
Our real magic is provided through complex backend manoeuvres when integrating with organisers’ and guests’ preferred calendar tool.
The simple interactions would not work better or perceived simpler if wrapped in a mobile application.
Also, a mobile application will not support the backend magic of integrating with users’ preferred calendar tools.
A two-sided ecosystem
We are building a two-sided ecosystem. To some extent, you could argue that we are building a simple social network. And most social networks are — unfortunately — based on mobile applications instead of just being an accessible web service.
“Unfortunately”, because social networks are 100% depending on already persuaded users, who should include more users to interact with the platform for the benefits of everyone.
To include new users — in our case the guests — we need to lower friction as much as possible.
Asking a guest to download an application to RSVP or interact with the host or other guests on an invite to a rather mediocre event is simply not going to happen.
Making these interactions available via an easily accessible browser link that works immediately is another story with much better conversion and interaction rates.
Simplification of our tech stack
Having built a bunch of digital products I have depended on early decisions while also being responsible for legacy systems 3 to 5 years down the line. Which means that I have experienced what chaos will reign if you start off with a complicated tech stack — depending on too many platforms and technologies.
Your service will break. Time is spent on bug fixing. Meetings for coordinating complexities. Development will slow. Everyone’s frustrated.
Getting off the ground with a simple web service while getting your head around your product, business and customers will make your life much much easier down the line.
Rapid development
Speed in product development is fundamental for success. Not only when launching but also while tweaking and adapting the following weeks, months and years.
A mobile application does not equal rapid development.
Building and maintaining a web service allows you to publish new iterations much more frequently. Sometimes several times a day. If new errors are made or found, a new version can be released and experienced in users’ browsers immediately.
Changes to applications to multiple platforms require a more extensive QA process. Application errors might need users to upgrade their applications — Upgrades which can take days instead of minutes to get in front of users.
Searchability
We have loads of great content in our public event invitations.
We want to be found. We want people to interact with our service. To try it out (See “immediate interactions”).
Even UI elements and descriptions are telling Google what you are doing.
Hiding your service and content away in an App Store does not make it easier for your customers to find your service and easily explore it.
Will Stuff ever be available as a mobile application? Maybe!
However, we will never default to a mobile application for the above reasons.
And it will require that some of the great advantages of mobile application will significantly improve the experience for our users.
So until then — Web service it is.
