Lest we forget, the term “app” has its origin in the word “application”, and more precisely, software application. With the introduction of the iPhone 1G and the famous “There’s an app for that” advertising campaign by Apple, the definition of “app” seems to have been quietly narrowed down to software that runs only on a smart phone or media tablet. If you’re planning a mobile software strategy for your business (and I think you should be), it’s important to be clear on just exactly what the term “app” actually implies.
In the late 1970’s when I was programming on this platform, we called the software a “program” and it was an all inclusive solution. It ran on one machine and used the directly attached storage and printers to get the job done. No network, no server to talk to, no Internet. No confusion.
When I later worked in a mainframe shop in the early 1990’s, we still used the word “programs”, but also called them “applications”, and they sometimes communicated with other applications via network links to destinations like the Federal Reserve Bank. As client/server PC technology then crept into the picture and “three-tier architecture” became the new buzzword, we spoke in terms of “client/server applications” and “mainframe applications” to keep things clear. Still very descriptive, and everyone understood the relative underlying complexities.
And finally, as the PC/laptop era went into full swing in the 2000’s, we just said “applications” no matter what the platform, and tech folks could still contextualize things properly in their own mind.
Fast forward to the iPhone 3 era, where we could now find consumers and current generation techies throwing the word “app” around as if it described software that could only run on their phones and claiming it’s something anyone can build on a Saturday afternoon. At this point, confusion, murkiness, and disillusionment enters the scene, because businesses desperate to have iPhone apps are finding themselves confronted with a harsh reality: building an app is not the same as building a web site. An app can be a complex animal, just like the mainframe programs of old.
Somewhere along the line, it seems the proper perspective on what an app really is was lost, or at very least, badly watered down. So whether you are crafting a comprehensive mobile software strategy, or just considering a single app for your business, here are some common app patterns to help clarify your thinking and gain some perspective:
- Brochure Apps. A brochure app is effectively a mobile version of your web site. It provides content about your business in a format that looks nice on the phone and is pleasure to interact with. This can be accomplished to a certain degree without the need for an app by simply making your current site mobile-friendly. This list of resources will get you started down that path. Your customer’s experience, however, will be better if you take the time to convert your content into a native phone app. Brochure apps are usually self-contained, typically the least expensive to build, and normally offered as a free download.
- Utility Apps. A utility app can be built to capture your intellectual property (IP) in a form that can be sold for profit. Perhaps you’re an engineering firm that’s developed a set of highly complex and specialized calculations used in a particular design or construction process. You could build a calculator app based on that logic and then market it to the appropriate sectors of the design and construction industries. Utility apps are more complicated to build than a Brochure app and will cost more to develop, but you gain the opportunity to differentiate yourself in the marketplace and earn additional returns on your IP. Remember also that you are not competing in the $0.99 game market. The price of your app can and should reflect the value it delivers. A utility app is typically self-contained and does not require network connectivity to be usable.
- Data Apps. A data app retrieves, processes, and presents information from a remote source, such as database server at your company, or from publicly available sources such as Google. They can be view-only, or they can be designed to allow information to be updated. At this point we cross the line into a new level of complexity – the so-called “back end server” that the app communicates with in order to retrieve and update data. Usually, this means that a network connection will be needed for the app to be useable, and you’ll need to consider if that’s realistic for your users. Will they need to use your app in places without wireless coverage? If you are building a Data app from scratch, this means you now have two parts to your design: the “front end”, being the app itself, and the “back end”, which is a web-based service you will either have to build from scratch or build as an interface to the public data source you need. Data apps are consequently more complicated and costly to build, and may require multiple skill sets and more than one type of software developer. Not all iPhone developers, for example, are capable (or willing) to do back end server programming. Back end servers also require regular care and feeding, so you will want to factor that into your costs.
- Transactional Apps. A transactional app allows your customers to transact business with you. This could be anything from scheduling appointments to actually purchasing products and processing payments. Transactional apps are the most complicated and costly to build (Disney-quality games excluded), have the front and back-end design of a Data app, and may need to be interfaced with one or more of your existing business systems.
Hopefully I’ve been successful in helping you see that building apps can be just as challenging as traditional software applications, because…they are traditional software applications in most respects. Some apps can surely be built in a weekend by a nephew (if he’s a good software designer and a talented graphic designer), but the time-honored mantra of “you get what you pay for” still applies.
Having fully convinced you last time that your business needed a mobile software strategy (I did, right?) , my goal here was to help you begin to understand the scope of what’s involved. If you have questions or want to go deeper, please feel free to contact me.
What kind of apps is your business using or planning on building?