What type of app do I need?
There are many ways to categorize apps, but if you’re not technical or don’t speak developer, it can be overwhelming to know what to ask for.
Do you need a native app or Android? Or perhaps a hybrid mobile app that uses an iOS wrapper so it can be used on an iPhone? Not sure? We don’t blame you.
So how about we keep this simple, and talk about three different kinds of apps we typically build so you know what works best for your business.
In this article, we’re going to organize apps based on the way they function or serve the people who engage them. There are three:
- A standalone app
- A user-to-computer app
- A user-to-user app
Because our approach to app development is based on the business needs of our clients, we find these categories help us determine usability, ranging from an interface and architectural standpoint, to the way we design user management and the kind of data transfer capabilities we include (or not).
Let’s explore what each type of app has to offer.
1. The standalone app
The least common type of app we build functions completely on its own –– it does not share information with external sources and doesn’t even need to be connected to the internet.
A simple example of a standalone app is one that you likely use daily: The Calculator app that is included with every smartphone or tablet.
Or in a healthcare context, it might be an app that reminds you to take medication.
These apps do one thing really well, and they don’t require data to be fed to them regularly to function.
Some key questions we ask when it a client is looking for a standalone app include:
- Is there no requirement (at this time) for the app to communicate to other users?
- Depending on what your app does, will it require a server to host data?
- Will your app solve a purpose for a specific user on their phone or their device that eliminates an immediate need?
It’s important to note that if you are considering a standalone app, but then hope to scale the product over time –– perhaps enabling communication between users, for instance –– we would have to build an entirely different app.
If you think you might want an app to communicate with users, or access data at some point in the future, you’re better off going with option two or three below.
2. The user-to-computer app
This product type sends and receives data from external servers or computers. Its function requires a connection in order to provide utility for its users.
That said, users of this kind of app do not communicate back and forth with one another.
An example of a user-to-computer app is an entertainment-focused service like Netflix. Users stream or download video from the company’s server, but are not going to regularly chat with other Netflix viewers, or talk to Netflix support about the shows or movies they are viewing.
Investment in video-based, streaming mobile apps is likely to continue to rise as consumers reported a 54% increase using this type of app in 2020, according to Global Web Index. But the user-to-computer model is highly applicable to a variety of other industries as well:
- From an enterprise perspective you may want to build this type of app for internal document management control or safety processes.
- In healthcare, it’s great for providing medical records to patients.
- And in financial services the model is the basis for banking or fintech apps where clients can check balances, make transactions and more
3. The user-to-user app
Finally, the most complex type of app we build is centred on user-to-user interaction.
In this case, there is a user-to-computer function because you can access a database behind the scenes to see historical rides or billing information. And there is also a user-to-user function where customers (riders) can connect with drivers in real-time.
Apps that are this user-focused are more applicable to some industries than others. For instance, most finance apps are one-way platforms and thus a user-to-computer model suits them best.
But in the growing healthcare application space, the user-to-user functionality works quite well.
To give you an example of something we built:
We developed a personalized senior home care app that connected several different user groups: administrators who oversaw scheduling, home care providers, patients and patient family members.
Not only did they need to be able to communicate seamlessly, but we also had to prepare for a variety of potential circumstances that might affect the efficiency of the service provided:
- What happens if a caregiver doesn’t get an order? Who would need to know about it?
- What happens if a caregiver is off for the day or sick?
- How does rescheduling work?
- What about customer cancelation?
No matter what type of app we build, questions like these –– that follow the entire potential user journey and consider the specific type of user solutions required –– are paramount. And the answers inform both the development and business strategy we move forward with.