For almost every business the answer to which to develop first, app or website, is the website. More exactly, it is a web application that works well on a phone, with an app following later if real use shows it is needed. The exception is a system whose main task cannot be done in a browser at all. This article is about the order of work, and about building the first piece so that the second is cheap to add.
One point of vocabulary first. “Website” can mean two things. A public website tells people who you are and how to reach you; it is a small, separate job, and you should have one whatever else you decide. A web application is a system that staff or customers sign in to: a customer portal, a job scheduling system, an ordering system. The real question is whether that system should begin as a web application or as a mobile app.
Why the web application usually comes first
It reaches everyone on the first day. A web application works on any phone, tablet or computer. You send people a link. Nobody has to find it in a store, install it or have a particular kind of phone.
The office needs it whatever happens. Setting up users, correcting records, running reports and dealing with exceptions are desk jobs. Even a system built round a mobile app needs a web back office, so that part gets built either way.
The first months bring the most changes. However carefully a system is specified, the first weeks of real use show what was missed. On the web a correction can be released the same day and everyone has it at once. In an app, each change is a new version that has to be published and then installed by every user, some of whom will not bother for weeks.
You learn before you commit. Once a web application is in use you can see who uses it on a phone, for which tasks and how often. That is evidence. A decision made before launch about what mobile users will want is a guess.
It costs less to be wrong once. Building a web application and an app together means paying to build an untested idea two or three times over.
When the app should come first
There are cases where starting with the web application would mean building something nobody can use.
- The core task happens where there is no signal for hours at a time, such as plant rooms, basements or remote sites.
- The system must record location or exchange data while the phone is locked.
- It depends on Bluetooth equipment or other hardware that a browser cannot reach on every phone.
- The app is itself the product, sold to consumers who expect to find it in an app store.
The first three do arise in business systems, mostly for field staff. If one of them describes your main task, build the app first, with a small web application beside it for the office. Our comparison of native apps and web apps sets out the kinds of app and what each can do.
Build the first version so an app can follow
The order matters less than whether the first piece is built to be reused. The expensive mistake is a web application that has to be largely rebuilt before an app can share it. Four decisions prevent that.
Keep the rules on the server. Prices, permissions, validation and calculations should live in one place, behind an API. An API (application programming interface) is the set of requests the screens use to read and change data. The web application’s screens use it today. An app’s screens can use the same one later, and every rule stays written once.
Choose a sign-in method an app can use too. Standard sign-in methods work for both. A scheme tied to the browser may not.
Design for phones from the start. Make the web application responsive, so that its layout adapts to a small screen, and test the main tasks on a phone before launch. This serves mobile users in the meantime, and it shows you what they do. Our tips for optimising a website for mobile users cover the detail.
Own every part. The source code, the hosting account and, later, the app store accounts should be in your company’s name.
A useful question for any supplier quoting for the web application: if we add a mobile app in two years, what will it reuse? The answer you want is everything except the screens.
How to tell that it is time for the app
Signs that an app is now justified:
- a large share of use is on phones, for the same few tasks, every working day;
- people report losing work, or being unable to work, where the signal is poor;
- staff or customers need alerts that email and text messages do not deliver well enough;
- a new requirement involves hardware, such as a scanner or a printer;
- customers ask for an app and, when asked why, give a reason a website cannot meet.
That last condition is worth testing. People often ask for an app when what they want is an icon on their home screen and not having to sign in every time. A progressive web app provides both. It is an extension of the web application you already have, at much lower cost than an app, and is often the right intermediate step.
Signs that it is not time:
- mobile use is occasional;
- nobody has asked;
- the complaints are that the web version is slow or awkward on a phone. Fix that first, because an app will not cure a slow system behind it.
A typical order of work
For a customer portal or an internal system, the sequence that carries the least risk looks like this.
- Plan. List the users, the tasks and where each task is done. Our software project planning worksheet is designed for this.
- Prototype. Mock up the main screens for a phone and for a desktop, and try them on the people who will use them.
- Build the web application. Responsive, with its rules behind an API. A defined first version of this kind is well suited to a fixed price.
- Run it and measure. Give it a few months of real use. Record which tasks are done on phones and what gets in the way.
- Add progressive web app features if they help. A home-screen icon, and offline working for the particular screens that need it.
- Add an installed app if the evidence supports it. Limit it to the tasks that need a phone’s full capabilities, and have it share the API.
Many systems stop at step 3 or step 5 and are none the worse for it.
If the public website needs work as well, it can go on in parallel. It needs little from the system beyond a link to the sign-in page, and it should not hold the main project up.
Decide in advance what would justify the app
Before the web application goes live, write down what would have to be true in six months for you to commission an app: which measure, and what level. It might be the share of orders placed from phones, or the number of jobs recorded late because an engineer had no signal. Agreeing the test beforehand means the decision is made on evidence, and it stops a second project being started because a competitor has an app or because someone senior likes the idea.