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). 

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.

The Most Important Question We Ask

September 8th, 2014 - by Brett Derricott - Salt Lake City, Utah

When a client contacts us about a new branding, design, or development project, we ask a lot of questions about the scope of the project so that we can propose an accurate budget and timeline. In addition to questions about the details of a project, we’ve started asking, “At the end of this project, how will you decide whether or not we’ve been successful?” Or, a variation that we’ve been experimenting with is, “When this project is complete, what will make you want to refer us to others?”

You might be tempted to think that the project’s scope is synonymous with the client’s definition of success. We used to think that too, but we’ve learned that’s not always the case. The RFP or statement of work is heavily focused on the what of the project, whereas declaring a project successful requires satisfying the why of the project.

For example, a client’s scope of work may list the following high-level deliverables which comprise the what of the project:

  • Brand refresh, including updated logo
  • New website
  • New business cards

But further discussion about the client’s definition of success reveals that we also need to accomplish the following to satisfy the why of the project:

  • The client wants to clarify their position in the market as the top-quality vendor, rather than compete on price.
  • The client wants to work with a firm that never misses deadlines (their previous agency frequently missed deadlines).
  • The client wants ongoing support after the project’s completion.

The original deliverables tell us what the client needs to have at the end of the project, but the additional details tell us more about the real results the client wants and what they expect from us during the project.

We’re not interested in merely checking off the feature list in a statement of work; we’re interested in happy clients who can’t help but tell others about their successful project. Making this happen reliably requires knowing the client’s definition of success at the outset of the project.

As an added bonus to better understanding the client’s real needs, we’ve discovered that asking this question also helps the client understand what they really want and this, in turn, helps them to better evaluate the various proposals they receive. When they’ve clearly defined the outcome they hope to achieve, the lowball proposals start to seem less appealing and a reputable firm starts to seem like a must-have…and that’s where we come in.


The Question You Aren’t Asking (But Should Be)

January 9th, 2014 - by Brett Derricott - Salt Lake City, Utah

It’s not uncommon for prospective clients to tell us they’re looking for a new agency because the last one let them down. The reasons vary, but not by much:

  • The agency didn’t hit deadlines
  • The client wasn’t happy with the creative
  • The cost far exceeded the promised price
  • The technology developed didn’t meet the client’s needs

Each of these could be (and at some point may be) the topic of its own article, but collectively these reasons all boil down to missed expectations. At Agency Fusion we’ve learned to avoid missed expectations by following a principle. I wish I could say we understood this principle beginning day one (2003) but in truth it’s a principle we’ve learned through experience. The (somewhat wordy) principle is this: The degree to which success is clearly defined at the outset of a project determines the degree to which success can be expected at completion.

Most agencies are experienced enough to spend some time in discovery or planning at the beginning of a project. They’ll ask the client questions to try to make sure the scope of work is clear and that the specific deliverables are defined. The client happily answers these questions and tries to communicate their need clearly. There is an abundance of communication at this stage which feels very productive and reassuring. This is when it’s fun to say, “Great! Let’s get to work!” But the most important thing, success itself, is rarely well-defined.

Deliverables get defined but deliverables don’t guarantee success. Schedules are created but schedules, even when met, don’t guarantee success. Plans and strategies and scopes, although critical, don’t guarantee success either. Success is influenced by planning, scopes, and schedules but success should not be assumed to be the automatic outcome of even the best planning. Success is its own thing, independent of the rest.

At the beginning of the project the client usually communicates in terms of deliverables: I need a website. I want a logo. I’d like a mobile app. The agency responds with great questions to clarify that deliverable, such “What will the app do?” or “Which mobile platforms will your app need to support?” All of these many questions are critical on the path to having a shared understanding of the scope of the project. They must be asked. But there is one final question that rarely gets asked: How will we both know if this project is a success? Or a variation: When this project is complete, we want you to be happy. What do we need to do to make sure that happens?

Whether it’s been articulated or not, the client has some kind of “success measuring stick” in mind. They’re envisioning some outcome or expecting some result and the agency takes an enormous risk to begin the project without knowing how that client will define success. Asking this one additional question will go a long way toward making sure every project ends with a happy client who is eager to refer others. And from the agency’s perspective…that’s the ultimate success.



Hourly vs. Fixed-Fee Billing

March 26th, 2008 - by Brett Derricott - Salt Lake City, Utah

This post is going to deviate a bit from the technical realm but I just read a report in the latest HOW Design magazine that was based on a recent survey of designers’ rates. One of the questions in the survey asked whether designers disclose their hourly rates to their clients.

The question, as written, seemed odd to me until I realized what they were getting at. This is how they should have asked the question: Do you bill your clients by the hour or do you provide a fixed-fee estimate?

I was disappointed to read that the majority of survey respondents bill hourly for their work.

Read the rest of this entry »