The case for web-based apps.
The case for web-based apps.
Why cloud or web-based apps are a better investment, have higher install rates, and higher user satisfaction rates.
Every week new clients ask me to write iOS or Android apps. I gently steer them to a cloud or web-app instead. There are three main reasons why cloud or web-based apps are better.
In no particular order …
Web-based and cloud apps are really the same thing, so I'll just call them web-apps. The main reason is that a web-app can be accessed via … well, … the web. And that distinction is important.
If an app needs no internet access to work – fine – I'm in total agreement that it should be a stand-alone, native app. But most apps today need some data from a server.
If an app needs data from the web, or a server, to work, then it's more like a front-end interface to the cloud-based server. eBay or the Amazon app are good examples. These apps are really interfaces to the web. They are of no value if you have no internet connection.
Why develop an iOS and Android app to interface with a web-server, when a browser can do the job?
When I develop a web-app, all user devices can access the app (desktop, laptop, tablet, and smart-phone). All users can all access it via a browser. And my client gets a huge benefit - one time development cost, one code base, one support log. With native apps, I need two (or more) code bases, more support worries, and often costs that are higher per user because we're supporting two platforms.
And that's the beauty of web or browser based apps. One development environment, one code base, and sure, lots of users to support. But at least the problems are not due to an Apple, or Android upgrade, dependent on some platform change.
Speaking of support. A web-app, that works in a browser means no support for installations. The device has a browser built in. My client just needs to direct users to their site. No installation is needed from the end user. No support calls because there was an installation issue.
This brings us to a trend. About 27% of users do not want to install your app on their device. If they can't connect with your data via a browser, then won't install your app. And you lose them as a customer.
This is true of me and my phone. I shop on Amazon, eBay and use Facebook. But I have none of their apps. I use Chrome on my phone to access these sites. No need to clutter my phone with unseemly apps. Which brings us to laptop and desktops.
Yes, many sites see a lot of mobile traffic. But 88% of all purchased are made from a laptop or desktop. SO … people shop with their mobile devices, but buy with their desktop. Wild I know! So the need tor a native app is overestimated. People need access to your site in a way that fits their needs.
Shopping may be a fun past-time on a phone while waiting in line. But buying is serious business and people like their larger screens for checking out.
The case for a native app is getting weaker and weaker.
When I use Amazon.com, I may shop on my phone (adding items into my shopping cart), but I checkout from my laptop. And so does my wife. We each add stuff to our cart, then talk it over, before checking out. And here we see a trend of people sharing an account across devices. Often people are talking over large purchases, or reviewing clothing choices with friends, before checking out.
Limiting use to mobile devices can reduce customers and user participation.
Developing for both mobile app platforms has: higher development costs, requires multi platform support, and reduces adoption rates from users who hate app clutter.
If all that weren't enough, the worry every time Apple or Android releases a new OS, can be costly and stressful. Browser updates, rarely require app changes.
So there you have it. My case against native apps. Sure, there are some cases where they make sense – but I think it's rare.
When companies have a one-off software project, it's not what their IT department normally does. It's too small to spend the time, and effort to staff for. Yet your team sees the benefit of custom software.
Often the bidding sites look attractive – at least at first.
Thinking about hiring with Upwork, Freelancer.com or Fiverr.com? Search online for all the complaints clients are having. At these sites you might find some good programmers, but it can be hard. One client put it best:
"At the bid sites, I got hundreds of bids. Many from people who could not do the job," Craig Windom said. "Many freelancers were bidding $500 when I knew the job was more like $2,000. It was just a waste of time."
On trustpilot.com a buyer wrote this:
"Upwork is sketchy.... Be careful....," Cher Power said. "One freelancer took my deposit of $1,710 and did not provide any work. They basically stole my money. I complained to upwork and disputed with my bank. In the end, my upwork account was suspended. There is absolutely no protection."
Why do business with bid mills, when there is a better way.
We make you the hero by reducing the friction to get one-off projects done.
First, your project is discussed to learn the key deliverables.
Next, you get recommendations to advance your project.
That includes defining the project so that time, cost, and deliverable expectations are met.
You know what you're getting, and what you're paying for.
If you want to move forward, we eliminate the billing, and W9 reporting hassles while increasing security.
You just use a credit card or paypal account to start the project.
You're protected with refund protection, we never see your credit card details, and all IRS reporting is automated.
You'll have a weekly communication slot so that you're always informed about the project status.
Lastly, we've been in business since 1987, so you can expect us to be there if you need updates.
If you want to know more, email [email protected]