The Objective Blog

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

Ready? Set? Deploy?

March 16th, 2020 - by Casey Harding - Salt Lake City, Utah


The big day has finally come. After months of planning meetings, design iterations, and development efforts, your web application is ready for launch! Discussions around deployment strategy and schedule are starting to take shape, but what does “deployment” mean, what does it entail, and what are some things to keep in mind as this milestone approaches?

Deployment: What Exactly Do You Mean?  

The word deployment is used in several contexts and can be more or less meaningful depending on what is actually being deployed. Technically speaking, a deployment is whenever new code or adjustments to existing code are pushed to the live site or application. As a user, it’s likely that you don’t notice the majority of deployments for some of your favorite apps, especially if the changes are minor or address background functionality and performance. It’s also extremely common to bundle and release multiple features and UI adjustments together; those reoccurring system updates for your phone or computer are great examples. Then, there are those extra-special deployments which are far more monumental: a completely new or rebuilt application is made public for the first time. This post is focused on this last deployment scenario. 

Save the Right Date

Imagine this: Everything’s ready to go. You schedule the deployment of your rebranded, rebuilt eCommerce store for Friday at 11:00 pm. On paper, this seems like a great time as it will hopefully mitigate the consequences of site downtime. However, when you go to check out the site early Saturday morning, all you see is a 500 server error message on what should be your store’s home page. In a panic, you try to contact the development team, but you aren’t able to get ahold of anyone. While this might sound like every business’ worst nightmare, this situation might have been avoided by simply scheduling the deployment for earlier in the week. We typically recommend deploying on a Monday or Tuesday and avoid setting deployment dates too close to holidays/weekends. If the new application will be replacing an existing product, scheduling a late-night deployment might be worth considering. If unanticipated bugs or errors are realized post-deployment, launching earlier in the week (either during or after business hours) provides greater assurance that the support team will be available to come to the rescue.

Getting to Launch: What’s Happening Behind the Scenes

  • Production environment setup and data migration (if applicable)
    Up until this point, your application has likely lived in a staging environment. A staging environment is a sort of “sandbox”, where functionality and interface improvements can be demoed, tested, and approved in a setting that resembles the eventual production environment.  That being said, there may be some configurations (for storage, performance, or security) that will come into play in the production environment but aren’t really needed for staging. Once a deployment date is determined, it’s time to get the application setup in a production environment, or in other words, on the server intended to house the public site. If real content or information was already inserted into the staging site but should also be present in the live application, some additional time needs to be set aside for data migration. 
  • Backup Configuration
    If your new application instance is replacing an existing one, it’s highly recommended to archive those old files in a safe place in case you need to roll back to the previous instance. It’s also a good time to get a backup schedule in place for the new application’s configuration files and database. In the event of a security breach or site crash, regular backups will mitigate data loss and help get your site up and running sooner. 
  • SSL Installation 
    SSL certificates offer an added layer of security to your web application by ensuring that all information passed between clients and servers is encrypted. Having SSL enabled has been an industry standard for quite some time and some search engines will go so far as to penalize your site for not having an SSL certificate in place. You can quickly tell whether or not a website has SSL enabled by looking at the address bar: the “s” in https:// indicates an SSL. To avoid potential penalties and to adhere to current security standards, we recommend that your web application has an SSL certificate installed either before or shortly after deployment.
  • DNS Updates
    In some cases, this is the final “switch” that will replace your old site with the new one. However, updating the DNS records is only required in a few common scenarios: 

    a. The application will use a new domain name that wasn’t in use previously. 
    b. The new application will be hosted on a different server than the domain was previously pointed to.
    c. Both a. and b.: The application will use a different domain name and will be hosted on a new/different server. 

    If the application will continue to use the same domain name and will reside on the same servers as the previous instance, there is no need to update the DNS records. In this case, the final “switch” will take place once all the new code files have been uploaded to the production server.

    In the event that a DNS switch is required and after the records have been updated, the only thing preventing you and the rest of the world from viewing the new site is the time it takes for those DNS changes to propagate. Hosting providers warn that this can take between 24 to 48 hours, but we usually see this transition happen much faster (between 15 minutes and an hour).

    Additionally, there are two other variables that may prolong the unveiling of your new site: TTL and caching. In the context of DNS, TTL is how often your domain is verified with the name server. It’s often set to 24 hours but can be manually adjusted through your hosting provider. Failing or forgetting to set TTL closer to 5 minutes might be the reason you aren’t seeing your new site right away. Secondly, if the issue seems to be isolated to a specific device, you may just need to clear your browsing history/caches/cookies or do a hard page refresh (holding down shift and clicking on the refresh/reload button on your web browser).

    To read more about domain names, DNS, and how website hosting works, check out one of our other posts here.

Some Other Pre-Deployment Items (if applicable)

  • Redirect strategy implementation
    If your web application is a rebuild, it’s likely that there are specific URLs (that users have bookmarked and google has indexed) that won’t exist on the new site. Prior to deployment, we’d recommend identifying these URLs and implementing a redirect strategy for each of those individual pages.
  • Email Setup
    Does your new site have a form that should send a message to a specific email inbox? Whether you are using a third-party service to manage submissions or not, verifying that transactional emails are set up and working in the production environment is important prior to launch. 


Deployments can come in all different shapes and sizes. The kind our clients tend to worry about the most involves the initial launch of a new or rebuilt application. If planned and scheduled properly, deployment days can be relatively seamless and uneventful (in a good way). 

The Database Dilemma: Part 2

February 19th, 2020 - by Casey Harding - Salt Lake City, Utah

If you missed it, in Part 1 we glossed over some of the benefits and limitations associated with the two prevailing database paradigms, relational and non-relational databases. In Part 2, we will give a more detailed analysis of the two approaches and give some suggestions when considering which to use. 

While the initial hype has diminished over the last few years, at one point there was a big push throughout the industry to replace the relational database with its non-relational counterpart. While relational databases were and still are powerful solutions, this pressure was not completely unfounded. With the ever-growing Internet of things and rampant increase of user activity on collaborative web applications, data in the 21st century have been generated and amassed like never before. “Big Data”, often unstructured or semi-structured in nature, has made it imperative for problem-solvers in certain spaces to employ an alternative, more flexible data paradigm. While there are certainly relevant use cases for non-relational databases, relational databases have retained their place as our go-to data store for most, if not all, of the web applications we develop.  

Why Relational Databases Are the Go-To 

Over the years, we’ve worked with hundreds of clients who come from vastly different industries. Through discovery conversations with our clients, we often are able to forge a pretty solid understanding of what data will be channeled into the application. At the same time, we can also determine, with some certainty, whether or not the data will likely remain relatively consistent over time. If the data appears to be mostly structured in nature and unlikely to dramatically change, we will more than likely suggest using a relational database. Data inputs that are clearly defined and have inherent associations marry well with the relational databases. Relational databases make it easy to optimize the relatedness of data sets and query the information in a rather streamlined, performant manner. 

Since all the information about a particular record lives within a single document in a non-relational database, it’s often difficult and computationally expensive to query for similar information stored across more than one document. With some of our non-relational database projects in the past, we have established joins on documents to mimic some of the behaviors and benefits that come from relational databases. However, this has often felt like a backward approach and we end up wishing we had just started with a relational database in the first place. 

When We Use Non-Relational Databases 

While relational databases seem to be the best fit for managing primary information collected and stored by web applications, more often than not, we will also utilize Redis and Elasticsearch for many custom web applications. Redis is a wicked fast key-value store, making it convenient for storing caching sessions. It can also be helpful in generating and scheduling task queues for background workers. Elasticsearch is another powerful implementation of a non-relational database. Known for its content flexibility, Elasticsearch allows for rapid and performant full-text search. Imposing a similar, comprehensive search of a relational database would require manual joins on all the tables or records you’d like to include, a process that can very easily become quite cumbersome.  Redis and Elasticsearch aside, if we come across a data architecture problem that would merit the use of a non-relational database, we would use one! Neo4j is excellent for graph-type data (think of user networks in social media platforms like Facebook or LinkedIn), MongoDB can be employed for unstructured “big data”, and DynamoDB is a handy key-value store.  

Our Recommendations   

  1. Know your data. We cannot stress this enough. Do everything possible to understand your data inside and out. Clearly defining your data set will not only help you to select the appropriate data paradigm but will also prepare you/your team with details that will likely impact the decisions you make throughout the project. 
  2. Map it out. If you’re caught in the middle, consider drafting a database schema. This brainstorming artifact and the process of creating it will likely provide valuable insight to support one approach or another. It may also highlight edge-cases in which retrieving groups of data might be more or less computationally expensive and/or complex to query. 
  3. Know your client/team. While this is and should be the least important factor in selecting a database, it’s certainly worth considering. In the case of agency work, it’s important that the solution is something the client is capable and willing to maintain in the long term. For in-house projects, selecting a database that your colleagues have working experience with may mitigate or eliminate the initial learning curve and potentially provide you with more resources to support the project in the short-term. 


When deciding on the appropriate data strategy for any given project, it’s extremely important to consider the consequences in terms of performance and data retrieval. While many factors can come into play, sometimes by virtue of a bad decision regarding the database, projects can require significantly more time and thereby impose avoidable frustration as budget and deadlines are stretched.

We’ve found that using both non-relational and relational databases can be extremely beneficial for the majority of applications we engineer: using relational databases as the primary solution for data that is relatively uniform and then employing non-relational databases for things like search and caching. As both paradigms evolve, it’s likely that the distinction between them will diminish. Until then, careful selection and utilization of both paradigms will greatly impact the ease, longevity, and scalability of the applications we build. 

The Database Dilemma: Part 1

January 29th, 2020 - by Casey Harding - Salt Lake City, Utah

One of the many things we love about the software world is how frequently new frameworks, languages, or tools will swoop into the scene and offer up new approaches to solving the problems we deal with every day. We get excited about new methods that challenge the old ways of doing things to help us do better work, faster. While it can be easy to get caught up in the hype, there are some paradigms that have impressively withstood the test of time and quite frankly, have done so for good reason.

Take databases for example. Since the early ’80s, relational databases have been the standard for structuring and connecting extensive sets of data. However, in the last decade, non-relational databases have gained avid support from the community, causing developers and data architects alike to reconsider using the former tried-and-true convention. At present, these two database types are vastly different and selecting one or the other will surely have significant impacts, for better or worse, on the applications you develop.  

Welcome to Part I of the two-part series, The Database Dilemma. In this article, we will give a brief overview for those who are “new” to the world of databases, distinguishing structured data from unstructured data and relational databases from non-relational. In Part II, we will take a deeper dive, leveraging some of our own experience working with the two paradigms. We will also give a few tips to consider when choosing the appropriate database type for your project. 

Structured vs Unstructured Data

To understand the trade-offs that come with either data paradigm, it’s important to recognize the types of data they appeal to: relational databases are great for structured data while non-relational databases tend to be better for semi/unstructured data. But what’s the difference between structured and unstructured data? 

Structured data is sometimes referred to as quantifiable data, while others will categorize it as being easily recognized and understood by computer programming languages. When we are working with structured data, we have a general sense of the nature and format of the incoming data and can thereby establish validations to keep data entries tidy, accurate, and organized with high confidence. For example, order information collected at checkout on an ecommerce website is an example of structured data. No matter the order, we can assume that a customer name, billing address, shipping address, and payment information will be retrieved and collected in a consistent, recognizable format. 

Unstructured data can be described as qualitative data, examples of which include, but are not limited to, documents, images, videos, server logs, and audio files. Data coming from multiple sources can in some cases be considered unstructured. This could be the result of each source delivering information in a unique, inconsistent format. Unstructured data tends to be less predictable than structured data, making it flexible but also difficult to impose validations on. 

Relational vs Non-Relational Databases

If you’ve ever entered information into tables on a spreadsheet, you are already somewhat familiar with how relational databases organize data. In a relational database, information is stored in columns and rows. Identifiers, referred to as primary and foreign keys, are used to establish connections between associated data housed in different tables. Prioritizing rigid consistency, relational database transactions are facilitated through SQL, the universal relational database query language, to ensure the integrity, accuracy, and durability of database transactions. This adherence to consistency and order is what makes relational databases the ideal architecture for structured data.

Non-relational (or NoSQL) databases, often referred to as document-based storage, are less like a spreadsheet and more like a file cabinet that organizes files into folders. They offer complete and total flexibility through a schemaless format, making them a godsend for unstructured or semi-structured data. At the peak of their hype, NoSQL databases boasted an inexhaustible ability to scale both horizontally and vertically, distributing computing power based on an application’s needs, a barrier that relational databases had yet to overcome. This concept of plasticity was traded for definite accuracy. The impact of this trade-off could be argued one way or the other; when dealing with gargantuan-sized data stores, the benefit of accelerated query performance could potentially outweigh an occasional transaction mistake.   

The Line is Becoming Blurred

Programmers and software engineers are always looking for opportunities to innovate, repurposing or borrowing from what’s available rather than wasting precious development time trying to “reinvent the wheel”. Over time, deciding between relational and non-relational databases might not be as difficult a choice as the overlap between the two becomes greater and there are more scenarios where either paradigm will work. For example, some non-relational databases will now allow you to employ foreign keys and indexes to sort and correlate sets of data in a way that resembles a relational database. The same goes for relational databases: by providing a JSONB field, some relational databases can offer certain aspects of the flexibility afforded by non-relational databases. Nonetheless, the current divide between the two strategies is still distinct enough that developers must consider the ramifications that will certainly follow using one paradigm in place of the other. 

In Short

Relational databases are like your Type-A personality friend: rigid and definite with minimal wiggle room. They stick to “the plan” to ensure the accuracy and credibility of database transactions. In contrast, non-relational databases are the ones with the “happy go lucky” attitude; their “go with the flow mentality” allows for flexibility when data is unstructured or semi-structured. Eventually, the two will likely inherit the benefits of the other but for the time being, deciding on one strategy or the other can have a substantial influence on the performance and maintainability of your application. For a more in-depth, comparative analysis of the two, stay tuned for Part II. 

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.

Software is Never Done

September 22nd, 2017 - by Brett Derricott - Salt Lake City, Utah

For first-time software entrepreneurs, the realities of creating and owning a software product can be a shocking eye opener. The trouble is, most have to learn the hard way. My hope is to give you some insights, gained after 15 years of designing and creating software for hundreds of clients, that will help inform you as to what you’re really getting into when you set out to create a new software application.

Incorrect Expectations

Most people who’ve never created nor maintained software are somewhat unreasonable in their expectations of what it will cost to create software that can achieve product-market fit, and unreasonable in their expectations of what it will cost to maintain that product after launch.

Based on my experience, expectations are often off-base because of the following reasons:

  1. The entrepreneur has never done this before. How could they know any better? If I decided to build a boat, which I’ve never done before, it’s safe to assume the project would take longer and cost more than I naively think it would. The same holds true for a first time software entrepreneur. We don’t know, what we don’t yet know.
  2. They’ve been conditioned to this thinking. There are many other things in business, even within a loosely-related category, that are more “pay $X and then you’re done”, such as a logo, computer, or brochure. Software, unfortunately, is not at all like this.
  3. Historically, software was a bit more of a static product. We bought software on discs and in the pre-Internet dark ages it was rare to get any updates for that product. I think this gives some precedent to the notion that “I’ll build an app and then sell it.” We still buy mobile apps that way, in fact, even though our mobile apps are constantly being updated.

The Dawn of Awareness

One of my favorite conversations with new-ish entrepreneurs is the one we have about a year after they’ve launched their app or SaaS product. By that point in time, the entrepreneur has usually started to realize that they will be working on this app (translation: spending money) continually for as long as they are in business.

They now know first hand that creating and maintaining software isn’t quite as simple as they originally expected. What leads them to this new understanding? It’s first hand experience of the following truths:

  1. All software has bugs. A hallmark of an inexperienced entrepreneur is that they believe in bug-free software. It’s a myth. Certainly, everyone strives toward that mythical goal, but no amount of money or expertise will prevent 100% of bugs. Get used to bugs, learn to prioritize them, and accept that they’ll cost you some money.
  2. Devices, operating systems, and browsers change…and they change often. Each change represents a potential problem for the software product, and some amount of effort must always be dedicated to keeping the software product up to date with the devices with which it must interact.
  3. Technologies become out of date or obsolete. Protocols get updated, libraries and frameworks evolve, APIs change, security patches need to be applied, and on and on. Your mobile app or web app lives within an ecosystem of other code and as that other code changes yours must change along with it.
  4. Your market changes. Even if you could build your product perfectly, your market and your customers are evolving, and that means your product has to keep pace. Your competitors are improving their products too, so forward movement is essential to stay relevant. You will need to invest heavily in your product for this reason alone.
  5. Your success will drive change. As you succeed in winning customers, their needs and the impact they have on your product will drive you to refactor code, optimize queries, build new administrative and reporting tools, etc. Your own success will demand further investment (which is a good problem to have).
  6. Technical debt must be addressed. Technical debt is an uncomfortable concept for product owners. Technical debt comes from tradeoffs developers have to make in order to meet timelines and stay within budgets. If you demand that your developers incur no technical debt, not only are you being unrealistic but you’ll never launch your product because you’ll forever be chasing the mythical perfect product. Technical debt will always exist, but you must devote some resources to keeping the amount of debt reasonable. Ignoring technical debt is also a good way to alienate your developers, by the way.

Avoiding Some of the Pain

Some of what you need to know is only going to be learned through experience. Some of what I’m telling you may not resonate until you’ve gained some mileage. But I do believe it’s possible to save you from at least some of the pain inherent in learning the hard way about the cost of creating software, and the following tips are offered with that goal in mind:

  1. Welcome the adventure. Have the humility to recognize that your expectations are probably a bit off, and welcome the experience of learning what it really takes to launch and own a software product. Like doing anything new, having an open mind and an eagerness to learn will turn your journey into an adventure rather than a frustration.
  2. Start small and conserve budget for the future. Even though you may feel like you have a perfect vision of what you want your app to do, start as small as possible, and iterate your way to that vision. If you do this, you’ll spend less money making the mistakes you will inevitably make. In other words, learn cheaply.
  3. Spend money on quality. While my previous point said to learn cheaply, the point is more about reducing the scope of your initial versions. Don’t go cheap on the quality. Cutting corners on quality increases your chances of having to start over or do a major rewrite of your software later. At least once a month we talk to a company who hired an inexperienced web developer (or an ad agency) to design and build an app for them, and the project is failing. It’s heartbreaking to have to educate them on why the money they’ve spent was nearly all wasted by an unqualified vendor.
  4. Get validation early and often. Validate your assumptions about the market as much as possible before you invest heavily in a product. Part of that market validation does require designing and building one or two versions of your product, but don’t spend hundreds of thousands of dollars trying to build the perfect product right out of the gates. Get validation first.
  5. Educate yourself about technology. You don’t have to become a developer, but if you’re going to own a software product you need to gain some technical knowledge so that you understand enough to manage those who will write the code. The more knowledge you have, the more effective they’ll be, and the more equipped you’ll be to avoid major issues.
  6. Find trusted advisors and vendors. The lowest cost vendor (or developer if you’re hiring internally) is rarely going to get you the quality you need. Avoid the siren song of anyone who tells you it can be done for significantly cheaper than what the other qualified sources are saying. Chances are they cheap vendor won’t deliver what you really need, and the technical choices they make will cause you major headaches and expense down the road. The best development firms are always going to give you a healthy dose of honesty and reality, which is often at odds with what you want to hear. If you’re tempted to ignore their candid advice, read #3 above, and then read it ten more times. You don’t want to be the firm calling us to find out if we can fix the mess you’re in. A reputable firm will also help guide you in terms of how you spend your budget so that you can balance quality with affordability.