The Objective Blog

Keep up with what we're thinking, reading, and doing.

Websites vs Web-Based Software

December 14th, 2018 - by Brett Derricott - Salt Lake City, Utah

Are any of the following true for you?

  • You’re about to hire someone to help you with a web project of some kind.
  • You work for a company with an online presence or product of any kind.
  • You’re a designer who wants to design for the web.
  • You’re a web developer.

If you said yes to any of the above, it’s important to understand the difference between a website and software that is accessible on the web.

There’s certainly a continuum, as shown below, where some websites do become more complex and some software products could be fairly simple. But the key here is to understand that there is a difference, and that the difference can in some cases be massive.

Websites vs web applications/software

To further break down the differences, let’s look at some key elements of websites vs. software that happens to be accessible via the web (also called “Web Applications”). Note that some of these bullets points aren’t hard-and-fast rules, but they should help you better understand the key differences.

A website:

  • Exists primarily to convey information.
  • Has information that is typically static and the same for all viewers.
  • May have a database but its primary purpose is to store the site’s content not the user’s data.
  • May have a CMS like WordPress or Squarespace to enable updating or maintaining the content.
  • Is often relatively inexpensive to design, build, and maintain; any complexity that exists is usually a function of the amount of content on the site or things like multiple languages, etc.

Web-Based Software (or Web Applications):

  • Often requires a fee to use (although a software product can still be free, like Facebook or Gmail).
  • Often requires a login to access.
  • Has information that is highly dynamic and changes frequently based on user input and other outside events/triggers.
  • Allows users to input, modify, remove, and otherwise interact with data.
  • Frequently involves integration of data with other systems and tools.
  • Involves algorithms, computations, calculations, reporting, transactions, etc.
  • Can be highly complex and expensive to design, build, and maintain.


Let’s look at a couple of examples to hopefully illustrate this more visually.

A Website

This is a marketing site, designed by a Web Designer, then developed by a web developer using a content management system (CMS):

An example of a marketing website.

Note that this site is informational. It consists of a number of pages that explain what the product does, the features/benefits, and how to learn more about it or request a demo. It isn’t an actual software product. Its job is to inform, promote, and persuade. It’s also much less complex compared to the actual software product.

A Web-Based Software Product

And this is a software product, designed by a UX Designer and a UI Designer working in tandem, then developed by a team of software developers:

An example of a software product or application.

Note that if you visit the link above, all you see of the software product is the login screen, behind which is a complex, sophisticated software application. The marketing site exists to inform prospective buyers about the software product. The software product itself is the highly complex tool that the buyer is paying to use.

Why it Matters

Here are a few reasons why it matters that you understand the differences between websites and web-based software:

Cost Expectations and Budgeting

If you’re hiring someone to help design or build something, it’s important to have an idea of the complexity of what you’re asking for so that your expectations are realistic. We frequently talk to people who are asking us to design and build a complex web application but who don’t understand why it will cost 10 or 20 times as much as the marketing site someone else made for them before.

Ability to Choose the Right Designer/Developer

Thinking that you want a website when you really want a web-based software product might lead you to hire the wrong designers and/or developers. There are a lot of designers and developers who can create a nice marketing website for you; there even tools that let you do this yourself, with varying degrees of success. There are far fewer designers and developers who can help you create an intuitive, user-friendly, robust, scalable software product.

Unfortunately a lot of web designers, or even graphic designers, don’t really understand what UX design is nor what UI design is. One evidence of this is how often designers lump the two terms together, and do it in the wrong order like this: UI/UX. When you see that on a resume or website, proceed with caution!

Hire the wrong people and you’re likely to be disappointed and waste both time and money. Many of the projects we do are for clients who had the unfortunate experience of hiring the wrong people to begin with.

Career Planning for Designers and Developers

If you’re an aspiring designer or developer it’s important that you start gaining the skills and experience necessary to succeed on the types of projects you want to do. It’s also important to sell your skills accurately, whether to a potential employer or to a client.


As mentioned before there is a spectrum or continuum from simple websites to complex web applications. Understanding the difference is beneficial to you whether you’re the one doing the work or the one hiring the people who will do it.

Accurate vs Expensive

June 18th, 2018 - by Brett Derricott - Salt Lake City, Utah

For over 15 years now we’ve been taking people’s ideas and turning them into reality. Designing and developing so many products has given us the opportunity to learn what it really takes to launch a product. That reality is often more than people expect.

When we meet with first-time entrepreneurs, it’s exciting to see the passion and energy they have for their startups. The optimism and confidence these entrepreneurs exude is a critical part of what it takes to brave the risks of starting a new venture! This optimism can, however, lead inexperienced entrepreneurs to underestimate the true cost of designing and developing a software product or app. It’s not just clients that fall victim to underestimating software projects, by the way! In our early years, we were often victims of overly-optimistic assumptions like most people are.


As soon as we have a fairly good understanding of what a potential client is hoping to create, we provide them with a rough cost and timeline estimate. When we present this estimate to a first-time entrepreneur, we almost always hear the same thing: “Wow, you guys are expensive!”

When we hear that, it’s tempting to think we need to find a way to be “cheaper”. We do want to offer the best possible service at the lowest possible price. If we can find a way to achieve a client’s goals for less money, we will always do that. We consider ourselves accountable to our clients and want to be good stewards of their money. We take this seriously and do all we can to be as lean and efficient as possible so that every client dollar goes as far as possible.

At some point, though, we can’t get much leaner. So if our estimates are frequently higher than what a potential client expects or hopes to hear, what might be the reasons for that?

  1. We’re trying to take advantage of the client and charge more than we should.
  2. We think the project is more complex than it really is, and we are therefore overestimating the cost.
  3. The project is more complex than the client thinks, and they are therefore underestimating the cost.


MVP is a Relative Term

April 27th, 2018 - by Brett Derricott - Salt Lake City, Utah

We talk to a lot of potential clients who have heard or read about the concept of a Minimum Viable Product (MVP). Thanks to the lean startup methodology, starting your new venture with an MVP is no longer a new, innovative approach; it has become the norm. In some ways that’s a good thing and in some ways it’s problematic.

First, the Good

Entrepreneurs are usually visionary people who dream in big, expansive ways. The lean startup movement has done wonders in countering the natural tendency of entrepreneurs to overthink and overbuild the first version of a new software product. Rather than spend all the money building what the entrepreneur believes is the right product, the lean startup methodology says to build only the minimum product that is necessary to prove viability. Entrepreneurs are now being taught to attempt smaller, more reasonable iterations of their product and I say that’s a good thing.

Now, the Problem

MVP is a relative term. A product’s viability is directly determined by the maturity of the market into which that product is entering. A product that is defining a new market can be viable at a much earlier point in time than a product entering a more mature market where healthy competition already exists.

Here’s an example to help illustrate:

One of our own products, a robust PTO tracking system, is called Built for Teams. When we launched our MVP version of the product years ago, the market didn’t really have any products dedicated to PTO tracking. There were some HRIS products that had a basic PTO tracking module, and there were some time tracking products that could record days off, but there was a lot of opportunity to define a new niche in the market.

Because of this open niche, we were able to launch Built for Teams with a fairly basic PTO tracking feature set. Our MVP quickly attracted customers who were willing to put up with the “minimum” state of our product because the few things we did were so valuable to them. In solving a few real problems, these early customers were happy to accept that our product didn’t yet do everything.

Fast-forward to the present and the market is quite different. Quite a few competitors have sprung up and, like any maturing market, we’re now in a race to do more and be better. To enter this market now, a new competitor has to build an MVP much more complex than we built for our MVP.

Your MVP

As you consider your own MVP, be sure to study your market and make sure you have a good read on what it truly takes to be viable. If you’re charting new territory, your MVP might succeed with just one feature and a poorly-designed UI. If you’re entering a competitive market, your MVP either needs to have a very unique value proposition or needs to be more complete in order to provide a compelling alternative to the established players.

Continue reading: I recently wrote about the product-market fit that an MVP sets out to accomplish.

The Radar: January 3, 2018

January 3rd, 2018 - by Isabel - Salt Lake City, Utah

Investing in AI

What every business should know before investing in artificial intelligence.

Full article

Strange Tech Stories

The 9 strangest tech stories of 2017.

Full article

Deep Learning Challenges

The results of deep learning systems are only as good as the data used to train them.

Full article

Top Tech for 2018

Read one author’s take on why React is the programming library of choice for 2018.

Full article

Robots Behaving Badly

If you’re worried about robots taking over the world, this article might put your mind at ease.

Full article

Bootstrapped Startup

Read why one founder chose to bootstrap their company instead of raising funds.

Full article



The Radar: December 28, 2017

December 28th, 2017 - by Isabel - Salt Lake City, Utah

Rounding Errors

Tips on avoiding rounding errors in responsive design.

Full article

Realtime API Solution

An open source library that helps turn rest APIs into realtime APIs.

Full article

Login Error Message Security

Learn how the standard login error message, “username or password is incorrect”, is not as secure as you might think.

Full article

Software Architecture

This video explores the benefits of generating consistent data types across all tiers in your software architecture.

Full article

Bitcoin Drops

Too late to invest in Bitcoin?

Full article

Elixir Stream

Learn how the stream type in Elixir works.

Full article