What Is The Last Thing You Do Before You Launch A Website?

Advertisement

One thing that can be said about human beings is that we are, by and large, creatures of habit. We establish routines, consciously and subconsciously, that help us accomplish tasks or move us more quickly or comfortably through our day. Habits are formed in the design and development community just as they are in nearly every other professional and personal environment, and they serve any number of purposes. In design and development circles, one established habit is seen with the launch of a website or project.

Naturally, each of us has developed a process that we engage in as we wrap up a project, but a few procedures tend to be used over and over again by the masses. We know this because we ran a poll on this very topic on Twitter1. We got many great responses, but the community tends towards a few common practices. We could see as we looked through the list of entries that certain wrap procedures seem to have mass appeal (judging by the number of times they were given as answers), so we began to examine the benefits they offered and what they say about those who fall back on them.

Designers and developers obviously adopt routines for a reason — perhaps because they suit their personalities or even their other routines — so it is possible to gain a little insight into those who follow them. There certainly was quite a range of responses, and we really appreciate everyone who took the time to get back to us with an answer.

Consider our previous posts:

Now, let’s examine the final steps that handfuls of people in the design and development community take when the clock says that it is officially “go time.”

Freak Out!

One of the responses that seemed to resonate among so many was, basically, to freak out as the launch date draws nearer. Who needs a calm and collected approach when you can run screaming back and forth in front of the computer and pull your hair out as the final hour draws near? The time-honored (even if impractical) tradition of panicking, which flies in the face of the hitchhiker’s motto, is not without its merits. However, for sanity’s sake and the sake of those who share your space, another approach near launch time might prove a bit better.

Freak Out
Image source6, by Maks Karochkin.

What our friends on Twitter said:

  • “Panic!”
  • “Cry.”
  • “Simple answer: pray!”

Benefits

  • There is a great release of pent-up energy when you freak out, which can have numerous benefits — one of which is no longer holding nervous energy inside.
  • A last-minute chaotic whirlwind of panic can also benefit the project because it ensures that you are alert and ready should any fault be found.

What This Says About You

Perhaps panic mode teaches us that those who fall back on such an approach lack organizational skills. The tendency to freak out more than likely stems from a lack of confidence that everything is in place. It could also indicate a slightly pessimistic outlook (à la Murphy’s Law): no matter how prepared you feel for launch, you have a nagging feeling that something will go wrong — not because you neglected something, but just because it can. A comprehensive check list could help to curb this tendency in some cases.

Relax

A somewhat different approach — in fact the exact opposite of the previous tactic — taken by many is to just kick back and relax. Though it may seem reasonable, relaxing just as a project will be introduced to the online world might not be an easy approach. In fact, achieving your desired level of calmness could take a lot of effort. If you can find your center and bask in relaxation during the pre-launch phase, then this approach might refresh you before you throw yourself into the next project.

Relax
Image source7, by VinothChandar.

What our friends on Twitter said:

  • “Get a good night’s sleep. Launch when you’re fresh, not tired.”
  • “Relax. Have a smoke, read some jokes online.”

Benefits

  • Peace of mind is naturally a welcome benefit of this approach, especially given how hectic things can get upon launch.
  • Mental decompression often helps because, as your mind is switches gears, your subconscious is free to review the project and scan for any missed elements.

What This Says About You

Being calm in the face of a wrap-up is not always easy. If this is your approach, it says one of two things about you: either you are extremely confident in your abilities, and therefore at ease because you know the job is as complete as you could have made it; or you simply don’t care — you’ve done your part, things are out of your hands, and you’re free to move on or just kick back. Confidence is not a bad thing; it could mean that you are prepared and thorough. Not caring, though, may not necessarily be a good thing — but you don’t care, so why harp?

Await Final Payment

Some of those who responded to our query take another route altogether: their final moves are all about the financial aspects of the project. They try to get paid. These people have run all their normal checks, and now they’ve turned for the final check from the client. Most professionals in the design and development community hold off on launching until the client has made their final payment. Whether that would be the final installment or full payment, the last thing on the check list for many is to collect everything owed for their work — and to stay in a holding pattern until that is done.

What our friends on Twitter said:

  • “Wait for final payment confirmation.”
  • “Send an invoice.”
  • “Get the cash!”

Benefits

  • One benefit of this approach is that you get to move on until payment is received, being freed up for other things.
  • It also puts the responsibility for ultimately launching the website on the client.
  • Finally, by not launching until you get paid, you ensure that final payment does actually come.

What This Says About You

One thing this tells us about the person who uses this approach is that they are trusting… to a point. They are willing to meet the client halfway and do most of the remaining work for them on good faith. But it also shows that good faith will carry the project only so far; this professional is not willing to give up their only leverage to the client. It also shows a certain level of professionalism, seeing as some sort of contract was agreed on before the project began.

Run Diagnostics

Some members of the community opt to run a final set of comprehensive diagnostics. They go through a full range of tests to determine whether any areas are still exposed to the elements as it were (speed tests, script checks, link trials, spell checks and so on). The list of oft-overlooked yet ever important details can be quite long and intimidating to tackle. But tackle we must, and some save this daunting diagnostic imperative until they are on the verge of launching. Several members of the community even create a helpful check list to aid in this phase.

What our friends on Twitter said:

  • “Test, test, test!”
  • “I go through my check list and see that I just forgot something. I check or preview the project before launch. I do simple and wide checks.”
  • “Test whether everything works properly and look for spelling mistakes. Tick off the project check list.”

Benefits

  • Of course, a full project diagnostic test will be beneficial, but doubly so if you’ve saved it for last, because no little changes you’ve made will fall through the cracks.
  • A thorough examination also brings peace of mind, especially when you use a comprehensive check list to ensure that everything is covered.

What This Says About You

Running diagnostics on your projects simply says that you are professional, sensible and efficient. While that may seem an impressive peek into your personality, those are not surprising qualities in the design and development field. But the depth of your diagnostics process gives a little more insight into who you are. If you take the time to conduct a meticulous check on a project, then you are more than efficient: you are anal, and your personality reflects that perfectionism. If you take a more lackadaisical approach and cover only a few key areas, then you may be efficient but have some traits of a slacker.

Final Cross-Browser Compatibility Check

One obvious and important check to perform at some point during any Web-based project is cross-browser compatibility, and according to the responses we received, some members of the community repeat this frustrating step before the project goes live. In fact, it is usually a safe bet that at least one browser will give you some sort of headache before all is said and done. Some resources can make these checks quicker and easier (we’ll link to them later).

What our friends on Twitter said:

  • “Do a quick cross-browser check…”
  • “Make sure it doesn’t totally explode in IE6.”
  • “Run through a quick check — analytics, etc. — and a last x-browser check.”

Benefits

  • The benefit of this kind of testing is self-evident. Saving it for last, though, generally gives you a sound starting point for the testing. However, it is always a good idea to test early, and test often. The earlier you test your working protoypes, the more likely you are to avoid compatibility issues in the long run.

What This Says About You

Checking for cross-browser compatibility is unavoidable. Leaving it for last simply speaks to your knowledge and ability to handle the full range of browser checks. What you check tells us even more. If you do a comprehensive test, it shows that you are responsible enough to see your tasks to completion. If you do everything but ignore IE6 (leaving its glitches in place), it shows you are responsible but have limited patience for idiocy.

Get An Outside Opinion

Another oft-mentioned approach is to turn to outside sources for opinions and feedback (always important whenever you do it). There is a reason why the saying about having a second set of eyes around has become so entrenched. Getting someone else in your field, whose opinion you value and insight you trust, to look at a project when you feel it’s ready is always useful. Given the size of the online design and development community and the willingness of its members to offer feedback, all you have to do is ask.

What our friends on Twitter said:

  • “Have someone test the website out, check for bugs and give you a quick review.”
  • “Pass the website over to a network of Web dev friends for them to pull apart and find anything you’ve missed.”
  • “Delete and start over (kidding). Send out a password-protected URL to a select group of Web buddies for a last look.”

Benefits

  • Getting feedback from someone who is not close to the project, someone who would see things you have overlooked, is always helpful.
  • A second look can reveal elements that don’t work as well as you would like or believe.
  • Feedback from people who are actually in your field is invaluable. Most other feedback tends to be vague and superficial.

What This Says About You

Anyone who makes this their wrap-up routine plays well with others. Those who seek input from others also possess confidence and understanding and rarely rely solely on their own judgment. They are secure enough in their abilities and know enough about their field to be able to handle professional criticism of their work. These qualities are also needed to implement the recommendations that they get. Also, you are at least somewhat likeable, having a network of trusted friends in the community.

Back Up

The final approach we’ll feature here is an extremely important step that is often forgotten: backing up all relevant data and materials before launching. Backing up all the parts of your project before handing over the files not only is sound and sensible, but in the event of an unforeseen catastrophe, it saves you from losing the entire project and having to start at square one. Backing up is an easy way to play it safe and cover your bases. You cannot know what will happen once the project is in the hands of your client.

What our friends on Twitter said:

  • “Make a snapshot of it (including data) and put it somewhere in case you need to restore at a moment’s notice.”
  • “I take an SQL dump of the database and store it somewhere safe.”
  • “Back up and archive! Twice!”

Benefits

  • Backing up is beneficial in and of itself, but it also saves you the headache of repetition if your diagnostics uncover an issue.
  • Backing up too early could inadvertently cause you to save an inferior version of the project. Then, if you need to restore the website, you won’t have the launch-ready version ready.

What This Says About You

Relatively few people tend to back up last. Doing so indicates a thoughtful nature and a completist approach to work. It also shows that you prepare for the worst-case scenario, either because you are a bit paranoid and pessimistic or because you like to play it safe (or a combination of both).

A Final Word

Thanks again to everyone who contributed to this post and made it possible, including all of you who have taken the time to read it. We have a few related resources for you to check out. After that, feel free to share your thoughts and your final steps before launching below.

Further Resources

As always, here are a few more posts and tools that might assist you in your final hours. Enjoy these helpful check lists:

(al)

Footnotes

  1. 1 http://twitter.com/smashingmag/status/10264136578
  2. 2 http://www.smashingmagazine.com/2010/04/21/five-tips-for-making-ideas-happen/
  3. 3 http://www.smashingmagazine.com/2010/03/02/web-design-criticism-a-how-to/
  4. 4 http://www.smashingmagazine.com/2009/11/05/invoice-like-a-pro/
  5. 5 http://www.smashingmagazine.com/2009/09/16/how-to-find-time-for-everything/
  6. 6 http://www.flickr.com/photos/karochkin/3674906958/
  7. 7 http://www.flickr.com/photos/vinothchandar/4469243936/
  8. 8 http://www.smashingmagazine.com/2009/06/29/45-incredibly-useful-web-design-checklists-and-questionnaires/
  9. 9 http://www.boxuk.com/blog/the-ultimate-website-launch-checklist
  10. 10 http://www.maxdesign.com.au/articles/checklist/
  11. 11 http://cameronmoll.com/archives/2008/06/web_accessibility_checklist/
  12. 12 http://articles.sitepoint.com/article/ultimate-testing-checklist
  13. 13 http://tgoden.com/index.php/the-ultimate-webdesign-usability-checklist/

↑ Back to topShare on Twitter

Robert Bowen is an emerging author, celebrated podcaster and poet, and most recently the co-founder and imaginative co-contributor of the creative design and blogging duo at the Arbenting Freebies Blog and Dead Wings Designs.

Advertising
  1. 1

    Nice read, good job!

    0
    • 2

      This is awesome…I just launched a new website yesterday, jacobbrowndesigns.com and I had a mini check list prior to launched. Great read!

      0
  2. 3

    Well written!

    0
  3. 4

    very nice,

    0
  4. 5

    I guess I tend to go the backup route. I also do a little bit of browser testing. It may be worth noting that about a week or so later I always come back and see how a site is shaping up on search engines. Sure this isn’t the first thing I do when a site is launched but it may be worth noting that a site being up doesn’t always make the project done.

    0
  5. 6

    I pray the Lord

    0
  6. 7

    Deadlines and launch dates?? What is this “stuff”?? Our office works on the concept of get it live tomorrow.

    0
    • 8

      @Steve: Amen to that. One place I’ve worked went so far as to be out there selling products with glossy brochures, which they THEN brought to us techies to make exist – preferably as of yesterday!

      0
  7. 9

    Something I find that’s really helping me is making use of Launchlist App. This makes sure that you go through a whole lot of necessary things and really gives you the guilt if you try to launch without everything prepared

    0
  8. 10

    Chris Schneider

    July 13, 2010 5:20 am

    I do a combo of a few of these. I typically collect half of the payment when I finish a design that both party’s agree upon, this gives me cash flow that doesn’t come from my pocket to setup hosting and URLs. After I get the site cut up, I drop it on the server, install the CMS, install lorem ipsum content, and then I cross Browser Test. I have come up with a pretty good base code for websites that generally doesn’t throw many cross browser issues so that helps. I then train them how to install content, and add pages, etc. etc. Once the training is done I give them a week or two to add content and then I tell them that once I receive final payment I will pull the login and password protection from their site so it is live! Keep up the great work! This was a good read.

    0
  9. 11

    Useful Info. Thanks for the post.

    0
  10. 12

    Great article. Now I see I have options other than to panic when it comes to launching websites.

    0
  11. 13

    For me its a mix of everything. I panic, I try to relax, I run diagnostics, cross browser compatibility checks, make a back-up and ask anybody and everybody for their opinions.
    So which one is best?

    0
  12. 14

    I empty my wallet.

    0
  13. 15

    I usually do a combination of these. Although I tend to test all throughout the project especially when putting it into XHTML/CSS before integrating it into a CMS. This way I can work out most of the browser issues before working on the CMS development, which comes with its own set of issues. As for mood, I usually tend to be calm before the launch if the client is happy with the design and development. However, if its a personal project, then I might get a bit stressed since its my own content going online.

    0
  14. 16

    I backup because of the Murphy’s law

    0
  15. 17

    Very good article!

    0
  16. 18

    Clear my calendar for the next month in anticipation of: “This is great, but you know, now that I think about it….”

    0
  17. 19

    Thank you Robert. you really made me think.

    0
  18. 20

    Victoria Blount

    July 13, 2010 8:10 am

    Before setting a website live, i do a mixture of the details above, from checking i have a back up to checking the browser compatibility, w3c and spell checking it.

    0
  19. 21

    Great post! BTW, I’m always trying to translate your works yet i’m sooooo busy…

    0
  20. 22

    Crappy article… filler, you guys are way better than this.

    Keep up the Good work.

    0
  21. 23

    This is a good article. It teaches you what you should be doing in the final stages of a website release. Too many people go into panic mode or sit and wait to collect their money. I do local and remote backups on all my websites weekly. I also do a backup on my Blackberry, just in case.

    0
  22. 24

    Cassandra Hansen

    July 13, 2010 9:11 am

    Hah! I love this article. It seems we do a bit of all of those things right before a big launch. It’s kind of a roller coaster of emotion over here :D

    Thanks for the article! Really puts the process into perspective.

    0
  23. 25

    Thanks for sharing!

    0
  24. 26

    This post focuses on the people who launch, glossing over a bit the part about why some of the more pragmatic routines exist.

    Backing up as the last thing – Even though this has been SOP at every company I’ve worked for, I can’t honestly see why you wouldn’t. The ability to revert to a previous working build is why version control exists for developers. It’s always a good idea to make a copy of an existing production site when it’s being upgraded too.

    Testing before deployment – Again, why would you not do this? Even though I have a QA department checking my work, more sets of eyes are better than less when it comes to testing.

    Relax – If you’ve met your deadlines, everything looks pretty solid and ready to go, relax. There’s no reason to freak out if you’re confident in your (and your team’s) work, but a little apprehension is perfectly reasonable.

    Aside from the last point, these are procedures which should be in place for any nontrivial deployment. These things say less about the people using the policies than the companies implementing them. If you’re at a company that knows what it’s doing during deployments, relax.

    0
  25. 27

    Ah, the joy of awaiting final payment! Working with large corporations and small, one or two-person businesses, here’s a tip on the final payment and the excuses people will use to get the work done before the final payment is made…

    “We can’t have a check cut and sent to you for at least a month but the site has to go live now!”

    “You can trust us. We’ve been in business for many years and we’re not going anywhere”

    “We want to see the initial reaction by consumers and then we’ll make some adjustments and THEN you’ll get paid.” (this is the red flag that they expect more changes beyond what has been paid for or contracted).

    Here’s the painful truth…

    A large corporation can have a check cut in as little as three days, for dire emergencies. There are several approval layers to peel through before the request ever gets to the financial department and there may be several layers within that department. A week to have a check cut and interoffice delivery to your contact person is pretty standard.

    A small business may actually take longer! The owner has to contact his/her bookkeeper, who probably services multiple clients, get them to cut a check, mail it and with all that and delivery time, it could be just over a week.

    No one really wants to pay you and they are still upset that you didn’t “trust” them and demanded a partial up front payment. How dare you care about money over the project!

    I say drink a lot…before and after the project.

    Great article, Robert! I think we get impatient towards the end of a project. It’s like the last half hour of a long road trip.

    0
    • 28

      Raphael Pudlowski

      July 15, 2010 1:36 am

      exactly Speider :)
      In no way, you make a website live, send PSD of projects, or the PDF to print, before the client has made the final payement.
      It’s a golden rule for the freelancer, and it should be on the contract.
      There are of course exceptions, when you don’t have choice (working on a regular basic with ad/interactive agencies, and in France almost ewryone is paying with a 3month delay… :/)

      0
  26. 29

    Refreshing article, interesting how a pattern like this can tell a lot about someones personality.

    Turns out, i’m anal.

    0
  27. 30

    Cross my fingers and hope like f***

    0
  28. 31

    Good job. It really works practically.

    0
  29. 32

    Last thing I do? Pray… & pray

    0
  30. 33

    very very helpful. I am launching bumped.in soon.

    0
  31. 34

    seems like “business as usual” but i still have that fluster gut feeling everytime.

    0
  32. 35

    Enrique Ramírez

    July 13, 2010 1:28 pm

    I usually compress everything that’s compressable.

    1) I put every .css file in a single one, then compress this, while keeping a source file with me in case anything needs changing.

    2) Same goes for javascript. I reduce the number of files as much as possible and compress them when I can.

    3) Lastly, I may use some sort of compression method to compress the markup code.

    4) Godspeed!

    This process allows me to also change any absolute urls that may need changing (IE filters, anyone?) as well.

    0
  33. 36

    Aside from doing one final backup and getting absolute client approval to go live, it’s time break out the Guinness!

    Of course once live, it’s always good to go through one last link/script test to make sure no absolute URLs snuck in there and hence aren’t working now that you’ve posted it to the root level. Guinness helps with the stress if you do find something. ;-)

    1
  34. 37

    I always pray…

    -1
  35. 38

    Thanks SM .
    Good read. Have launched 4 projects this year. This post really helped me put things into perspective. I could relate well with the pre-launch fever.
    God bless you guys for maintaining a high quality and standard at SM .
    Cheers.

    0
  36. 39

    great article :) very informative

    0
  37. 40

    You forgot GO TO THE PUB :-)

    0
  38. 41

    praying always…been thankful.

    0
  39. 42

    very nice

    0
  40. 43

    Thanks for all the comments and additional feedback. I was really excited with all of the responses collected from Twitter about compiling this post. It’s always interesting to see just which of the important steps we all save for last, which after all, is supposedly where we keep the best waiting. :) Thanks again.

    0
  41. 44

    get drunk? :)
    ok that’s actually after…

    0
  42. 45

    Great article – really enjoyed reading it

    0
  43. 46

    wow Great Article just launched my site. I had forget to take backup now i will do it

    0
  44. 47

    Compatibility tests ? backups ? spell check ?
    come on! this is part of development !
    Are you guys waiting to do all of those things up on site launch ?

    Then I must say: you are working in a very bad way!

    Make the website available to the world, turn off the office lights and go home.
    That’s how it should be.

    cheers – keep on smashingmagazine

    0
    • 48

      This was my first thought! If you’re ready to launch a site but still need to browser check it and spell check etc – you’re nowhere near ready to launch!

      0
      • 49

        Vitaly Friedman

        July 15, 2010 1:11 am

        Actually, I guess the point was not to check the site for cross-browser compatibility, but to do a final last check (the last among many compatibility tests before that) to ensure that no mistakes or problems were introduced during the last tweaks in the final stage of development.

        0
  45. 50

    Reasure the client that everything will be ok.

    Bugs and either too high or too low traffic are normal problems at launch. No matter how much testing you do before the really-real users start pounding it they always seem to find new and creative ways of breaking the system. Or some external provider like Facebook doesn’t want to play ball.

    The most critical thing we do it to talk alot with the client, often giving them large doses of hugs and/or valium. Keeping my head cool and answering each and every panic-driven question from the client is a huge pain in the ass, but it’s part of the job.

    0
  46. 51

    Usually I change my address, take all my money from the bank and pretend I’m dead. After a couple of weeks I settle down in another city and start a new life until I have to launch a new web site.

    0
  47. 52

    Brilliant post…Thanks SM

    0
  48. 53

    Spelling / Grammar Checks:
    Surely this is the client’s / copywriter’s responsibility to supply grammatically correct content? I am quite the spelling nazi and have been known to slam down the grammar hammer on occasion, but I have way too many, more important things to check than make sure that the use of your and you’re is correct. Sure, if on the off-chance I spot something, I’ll change it, but the client isn’t hiring the part of my skill set known as ‘being able to read’.

    I agree with the other Diagnostic stuff though…my main one is Web Optimisation. It’s amazing how lazy people are getting as internet connection speeds get quicker. I use http://www.smush.it/ to squeeze down image filesizes; the usual culprits are ones exported from Photoshop with all its additional information. I also hunt around for stuff that could be condensed with CSS-spriting, if it hasn’t been done already. On my last project I managed to shave something like 1.5MB off the generic template alone by investing an hour or so into my endeavour. 1.5MB doesn’t sound like much but I’m sure the smart-phone visitors will appreciate the quicker load-times.

    Cross-Browser Compatibility should be done WAY before launch! I don’t think you can ever avoid stuff dying in IE6, and any decent Front-End Developer should be able to write their code with knowledge of the majority of stuff that IE6 will throw back at them. Obviously check stuff yourself, but I’ve found that a good trick is to place the site on a public-facing development server as you iron out the kinks (‘snagging’) and give the link to the client. Chances are they’ll view, link to a friend about “what’s coming soon” or even send it around the office to ask the opinion of the staff; this invariably creates a small testing group of ‘normal people’ with some pretty unique browser / resolution set-ups, and the curiosity to click around more (than you). It may seem a little unprofessional to get others to do the dirty work, but it’s less embarrassing than something cropping up months after the project was ‘signed-off’.

    Await Final Payment:
    A contract should be legally tight enough to allow you to claim final payment AFTER submission (not on)…therefore, there’s no real need to sit there with your hand out to the client whilst your other hand hovers over the ‘Put’ button.

    0
  49. 54

    Mark Fitzpatrick

    July 14, 2010 6:55 pm

    Wow, pretty cool stuff. I am in the process of establishing my website (I am a photographer) and this list will certainly come in handy when it comes time to launch.

    I think I have actually been lucky enough to skip the freak out phase because I am working with a pretty incredible graphic design business. If anyone is ever in Australia and wants a good group of people to help you with web design check out DPM Creative Group located in Sydney.

    0
  50. 55

    Great list of things to do, I’ll be sure to remember some of these when launching my next project.

    Steven

    0
  51. 56

    I used to check and recheck during an entire project, this cost me a lot of time. Since I been doing tests just before launch, my production has actually nearly doubled.

    Great post! Keep it up.

    0
  52. 57

    Moksha Solutions

    July 15, 2010 2:00 pm

    nice tips

    0
  53. 58

    Make sure the check clears.

    0
  54. 60

    good!

    0
  55. 61

    what i like about SM, they write very simple which results in better understanding of whole thing

    0
  56. 62

    I’m in the process of relaunching my blog, but my coder is extremely late being 1 month behind the scheduled turnaround.

    Is there anything to do about this or should I just sit and wait?

    0
  57. 63

    I backup and make some submissions to other sites for some start links :) .

    0
  58. 64

    I drink a beer (or two)

    0
  59. 65

    Look at these
    κατασκευή eshop

    0
  60. 66

    I usually run a beta test on UserFly to get some quick feedback for about a week or so, review the results and make the proper changes, then sit back and have a few cold ones. ;-)

    0

↑ Back to top