When to Build a Website vs. a Web Application

The other day, I had a spirited rant discussion with my friend who is a franchisee of a supply chain company. She was looking for business advice and had to decide between staying with the current system or developing one of her own. One of her advisors mentioned that the current website platform (a service that manages franchises and deliveries for customers) can easily be recreated for between $10-20K. I got worked up (as usual) and offered my two cents. Though this was a web-based system, it was far from a simple website. I was dumbfounded at how effortlessly this was passed off as a simple bump in the road.

The system provided a very customized service, and I could identify at least 13 significant features, which could be broken down into hundreds of user stories. One of these features was the ability to automatically identify inefficient transportation routes, and print route sheets for drivers across different franchises and locations. Because of this, it was clear to me that the advice my friend had been getting was ill-informed.

Maybe it’s because I work in this industry every day, advocating for the complexity of simple things, that I sadly see this disconnect all too often. Some consultants are convinced that you can recreate Facebook with a Weebly theme. It occurred to me that, in the short 10-15 years that websites have been used seriously by corporations and businesses, they have quietly evolved from basic one-way communication platforms to full-on integrated business software.

Websites vs applications

I like to think of it this way: a website is something you read, an application is something you use. Some websites are applications and vice versa, and some happen to be on a scale that is better described as an application.

It’s often a struggle to get clients to fully understand the true scale of a project until they are midway through planning. For the majority of users, they can rarely assess the size of a website or application if it’s executed well. They will effortlessly browse between a local taco shack’s website and then transition to Facebook, without recognizing that they have essentially gone from a camping tent to the Taj Mahal with the click of a button.

People are often shocked when I explain how many web developers are staffed at most companies like Amazon, Etsy, eBay, etc., and even more surprised when they learn how the creation of the smallest feature such as a ‘like’ button dwarfs their entire website budget.

There isn’t a universally accepted distinction between a website and a web application. You could argue that every website is an application, just to varying degrees. However, when you refer to websites as software, it tends to elevate its position from merely a communications vehicle, to a more centralized business function. Calling it a website often undermines its importance and can jeopardize the success of a project.

Consistently underestimated

Most of us know people who have gone through some sort of website redesign in their past, and “piece of cake” is never used to describe it. From long delays on decision making, to full staff meetings to discuss ‘how fast the carousel will rotate’, to testing and deploying, and the guaranteed content lag - the general consensus for first timers is usually “more effort than I expected”. To gain serious consideration and engagement of management, we need to stop thinking of complex applications as ‘just websites’. This will not only make for a higher quality end product, but will result in smoother delivery.

If we look at most websites being developed today, it’s obvious that the days of brochureware are behind us. Most^* projects involve some sort of:

• Secure customer, member, or employee authentication
• Integration with third party services such as inventory management, HR database, APIs, or analytics
• Content management, automation, syndication, workflow
• Multiple authors with different user permissions
• Financial transactions
• Security
• Information design from third party data sources
• Custom forms and backend database creation
• Multi-page transactional design
• Varying levels of social media integration
• Data capturing
• Rich front-end user experience, optimized for multiple devices and browsers
• GPS mapping and geolocation

If my friend and her business advisor were to look at their current website and compare it to the above list, they would quickly recognize that it’s definitely a web application, and one should think twice about trying to recreate it without a serious investment.

Service blueprints

Lately, my colleague and Design Director, Zach Perkins, and I have been running more workshops^** aimed towards digital managers. We find that Service blueprints are a good way to realize the size of your digital footprint. By mapping out key interaction points, you are forced to think about all the backend systems that are affected with each touchpoint. Service Blueprints aren’t new by any means, as they are traditionally done in the world of IT and Business Analyst consulting, but we find that they are a quick way to present the importance of the website as a core system, which stimulates management buy-in.

We need to collectively rethink what digital means for an organization. For most enterprises, it embodies the core of operations and is a foundational piece for future success and survival. For other organizations, the application IS the business, which should bring on a whole new level of effort and madness. Another topic for another time…

*I do realize there are plenty systems that exist which can be leveraged and reduce the amount of custom web development, yadda yadda modules & plugins yadda. Future blog topic, I’m sure.

**We just happen to be running a UX Planning Workshop on May 21st. If you’re interested in joining us, send us a message. If you do any sort of website planning or project management, you will find this very helpful as you will learn different design strategy planning methodologies that you will be able to apply to your own project.