Over the last ten years I have managed the development of dozens of websites and have contributed as a writer to dozens more.
All these projects have convinced that most website projects shouldn’t take as long as they do. We’re not putting men on Mars here. Assuming you’re not building a full-fledged web application, your site will have anywhere from 5 to 50 pages of content.
So what gives? What root causes explain why simple websites—what developers refer to “brochure sites”—become a comedy of errors? (Actually, a tragedy of delays would be more accurate.)
Let’s delve into six ways that you can shoot yourself in the foot (and annoy your web developer at the same time).
1) Missing Assets
A website is, in essence, digital duct tap wrapped around image and text files.
Most of the actual work goes into that duct tape, and though writing code can eat up many hours of time, developers want to write code. Writing code is how they get paid, so it is in their best interest to do the work. (Granted, developers may procrastinate or mismanage their time, but for the most part, they want to get paid.)
And neither is the wireframing and design phase the underlying cause of major delays. Like developers designers want to get paid. My designers can produce beautiful wireframes in a week or less, and they typically nail the rough design and layout on the first go. Assuming we can get approval within a reasonable timeframe, finalizing the designs might take another week.
So where do the delays originate?
A website cannot live on code alone. We need all the assets that stick to the digital duct tape:
- Vector file of your logo (typically with an .eps or .ai file extension)
- Other brand assets, including your corporate color palette and fonts
- High-res headshots for your team members
- Other photos for your products, services, or projects
- High-res video files
- Written content for the various web pages
- Client logos
- Case studies
- Product spec sheets
- PDFs of brochures and other sales collateral
And the list goes on. You begin to see the issue in the sequence of events:
- The client orders up a website.
- The developer says, “Before we can make any real progress, I need this list from you.”
- The client says, “Oh. Okay. Let me get back to you.”
- The developer waits.
(Cue the Jeopardy theme song.)
If my clients are short on anything, it’s time, so it’s easy for tedious tasks like “Find the logo file Austin asked for” to get buried under more urgent tasks.
The client demurs. The developer twiddle his thumbs. Developers certainly don’t want to play Sherlock Holmes in their clients’ hard drives, and they usually don’t have access anyway.
Before you know it, a tiny detail like locating the vector file or the CEO’s most recent headshot has stalled out the entire project.
If you want your website to proceed smoothly and quickly after those exciting discovery sessions, then tie off these three items beforehand:
- Most of your assets already accounted for;
- Time-boxed plan to find missing assets; and
- Contingency plan—that is, extra budget—to create any design, photography, or writing that can’t be found or never existed
Or you can cater to my preference, which is skipping straight from #1 to #3. I prefer extra budget for three reasons:
- I get paid more. (Of course I would recommend this option, right?)
- I can bring in my favorite design, photography, and writing freelancers and pay them to do what they do best.
- I gain more control over the timeline, which means that I can bring the project to a successful conclusion faster.
This extra budget means fewer obstacles, less friction, and launching the website sooner. Launching the website sooner is good because then it can start paying for itself sooner.
2) Missing Credentials
If missing assets don’t get you, missing credentials will.
To kick off a project, I ask my clients for these log-in credentials:
- Website Hosting Account – We will need some place to store all the files. Your website hosting account is your digital storage unit. DreamHost, Hostgator, and Namecheap are three examples of large hosting companies.
- Domain Registrar – Your domain registrar is where you registered your domain. For example, AustinLChurch.com is registered with GoDaddy.
- Content Management System (CMS) Admin Portal or Dashboard – You will log into this dashboard post-launch to make changes and do routine maintenance. Notable examples include WordPress, Joomla, Drupal, Squarespace, or Craft CMS.
- Google Webmasters Search console – We want to keep Google happy so that you have better SEO and get more organic traffic. To do that, we’ll need to, among other things, optimize your website’s loading speed and ensure that Google’s bots are crawling your site and indexing all the right pages.
- Google Analytics – We will integrate analytics with your new website or ensure a smooth transition from the old site to the new one.
- Your Email Service – We need to make sure that transitioning from the old to the new site doesn’t blow up your email.
If we are building your first website or if your existing website was built using static HTML, then you won’t have have a CMS. That’s okay. We’ll set one up for you.
And we may also ask you to change hosting companies. We prefer to build a fully functional test site on a staging server before we go live with the final version of the site that you approve. Some hosting companies make pushing a site from a staging (or test) server to a production (or live) server unnecessarily complex.
Other hosting companies make it easy to follow these best practices, so we prefer to host our clients’ sites with them.
It’s a win-win. Your site takes less time to build and launch, which means fewer headaches for us and lower costs that we pass on to you.
Wait. I’m getting ahead of myself. The problem isn’t that clients don’t trust us to make the right recommendations. The problem is that when we ask clients for the keys to their house, they don’t have them.
We may spend many moons and more emails trying to track down the username and password for your hosting account.
This sleuthing work is like trying to unravel the plot twists in a soap opera:
- The client had the credentials but misplaced them.
- Or, someone at the company, such as the office manager, had them and subsequently left the company. The credentials got lost in the shuffle.
- Or, the client never asked the original developer for them.
- Or, the client asked the original developer, but s/he made a case for not sharing them—e.g., “Sending via email isn’t a good idea. What if your email account gets hacked?” Both parties dropped the conversation.
- Or, the client and the original developer had a misunderstanding.
- Or, the client didn’t pay one of the developer’s bill, and the developer responds in kind by holding the credentials hostage.
Such drama and intrigue!
To be fair, conscientious developers are reluctant to share credentials because they don’t want a non-expert logging into the hosting account, doing dumb stuff, and jacking up the website (which the developer will then have to fix).
Even so, the mad scramble to locate credentials is so common it is hilarious. Smart business owners whose companies generate X millions in revenue each year can’t who access their own websites: talk about a liability!
The remedy for this situations is obvious.
- Before you ask your new developer to add you to his or her production queue, go ahead and gather up all of those credentials.
- If you can’t find your username and password, then contact the companies or use initiate the “forgot password” sequence.
- If you cannot even name your domain registrar, website hosting company, and content management system, then look up your site on whois.net. You might find some clues there.
- Then, ask your new developer to look at your website’s source code and figure out whether you have a static HTML site, particular CMS, or some other Frankenstein creation.
- Keep them in one central location. LastPass, 1Password, or even a Google Sheet with restricted permissions will do.
Pro Tip: If your developer ever tells you he can’t email your credentials, ask him to write them down on a sheet of paper and text you the photo.
3) Missing Decisions (or Too Many Decision-Makers)
Once we get the assets and credentials, or at least have a plan for getting them, we can start on the real work.
And once we mock up page designs and write first drafts of content, you will have to give feedback. You will have to make decisions.
At Wunderbar we have encountered at this most delightful of junctures two specific challenges:
1) The decision-maker becomes a moving target. We can’t pin you down long enough to get an answer to our questions. We need for you to say. “Yes. Looks good. Let’s proceed.” Then we can hustle on to the next task.
2) Two stakeholders give contradictory feedback. They cannot agree on the right color of blue or which version of the mission statement to use.
Maybe you’ve heard the term “design by committee”? The negative connotations are well deserved.
Consensus is important. Leaders and other stakeholders must have clear, copious, consistent communication. They must agree on the company’s vision and the path toward it. A house divided against itself cannot stand.
But unfortunately, what we have encountered is that dialogue around the website—design direction, branding and positioning, content strategy, and even the decision about who has ultimate decision-making authority—opens a can of worms.
Suddenly, unresolved conflict rises to the surface. Suddenly, “the website” becomes about winning a fight, not moving the company forward.
Should the admittedly brilliant CEO choose the primary, secondary, and tertiary colors and fonts simply because he is the CEO? What if he’s one of those people whose expertise goes deep but not wide? What if he can barely match a tie to his button-up shirt?
A thousand decisions can result in a thousand disagreements. The buck needs to stop with one person. Who is the right person? And how can you avoid wasting time on flareups and disagreements as you try to build consensus?
- Turn your “design by committee” into a single decision-maker.
- Determine in advance who that person is.
- Make it clear that the whole team, including executive leaders, must respect that person’s authority.
- If you are not that decision-maker, do your very best to not meddle.
- Agree upon a timeframe for making decisions with your developer. For example, I typically give my clients 48 hours to review web content. Or I might send them several logo concepts on a Friday afternoon, and ask them to pick one by the following Tuesday. Decisions without deadlines become delays. (You should tweet that.)
- Carve out margin so that you can make decisions. Nobody likes feeling rushed while making important decisions.
Chances are, if you’re dragging you’re feet, it’s because you didn’t block out thirty minutes in your calendar to read the web content, mull it over, and respond with a bullet-point list of edits.
This isn’t aerospace engineering. You can make decisions within 48 hours if you actually take the time to review what your web developer sent.
4) Decision Fatigue
Decision fatigue is a real phenomenon, and web developers contribute to their clients’ fatigue by asking them to flex their decision-making muscle for too many times.
The fact is, when it comes to websites, I have more experience and expertise than my clients. I usually make better decisions for them than they can or will make for themselves. By sending them five WordPress themes and asking which one they like the best, I am not empowering or serving them. I am contributing to their decision fatigue.
For busy owners and executives, more choices doesn’t equate more value.
More value is simplicity. More value is speed. More value is a seasoned professional providing a done-for-you service and liberating clients from dozens of decisions. McDonald’s gives you a hundred options, but Michelin star restaurants give you a pre fixe menu.
Based on a decade’s worth of close observation, I believe my clients care more about “Done” and ROI than extra options and true originality. Were I to give them extra options, I would be serving up a hot plate of analysis paralysis.
So my web developer friends, this one is on us. It’s up to us to restrict the flow of decisions so that our clients can focus on the ones of true import and impact.
For example, if I’m building a WordPress site and it’s not fully custom, then I prefer to use the Divi theme from Elegant Themes (affiliate link).
It is a fine option for most of my clients, so I will say something like this:
“This is the WordPress theme I think we should use. It has the flexibility we need in order to do some light customization and add your branding. Also, the people who created the theme are still in business. They can help us if we run into any issues. I simply need a yes from you so that we can move to the next step.”
Yeses are important. Client buy-in is important.
But if you really want to do your clients a solid, then simplify their lives by giving them fewer choices to make.
Brief Caveat on Trust Issues…
For Developers – If your clients don’t trust you to limit their choices, then you haven’t positioned yourself as the expert. You are the order taker, not the trusted guide. You might want to take a closer look at your own branding and positioning. Or you might need to phase out old clients and get new ones who do trust you. In the meantime, if you have a tolerable client who wants to be involved in every decision, then double the timeline. If you have a client who second-guesses your every decision, then have a come to Jesus chat with him or her. (Before you do, check out Carl Smith’s story in this post.)
For Clients – Don’t hire a team that you don’t trust to make expert decisions on your behalf. Not sure whether you will like their choices? Ask to see some of their past work. Ask for references. Once they pass muster, set them free to do what they do best so that you’ll be free to do what you do best. You can do that with a simple request: “Please bring only the most important, impactful decisions to me. Otherwise, make choices for me that are at least as good as the choices you’d make for yourself.”
5) Missing Deadlines
We human beings struggle to prioritize long-term gains above short-term losses. Doing so causes mental static.
I do this all the time. A client has an emergency, and rather than finish writing my new bio so that my web developer can get it up, I help my client. This is admirable, and under most circumstances, helping a client or customer solve a problem is a surefire way to stay in business.
But new websites aren’t severed arteries, which is why you need a polite but firm project manager to crack the whip.
We get excited about what a new site can do for our companies, and both the client and the developer enjoy building momentum. Both benefit from meeting or beating deadlines. Both want to bring the site to a successful conclusion because the client wants ROI and the developer wants repeat business, a testimonial, and referrals.
Yet, the design and development process itself may feel like a part-time job: “Review this. Approve this. Pick three. Remove two. What is your final decision?”
Multiple milestones and deadlines help to keep the project on track because they break up a huge, monolithic undertaking into more manageable goals.
At the same time, missed deadlines are the canary in the coal mine. They indicate ineffective project management.
So pick 6-8 deadlines for your project. Stick to them come hell or high water.
For Clients – If you have a history of being “slippery,” then take a novel approach. Overpay your developer by $6,000, and have them refund $1,000 for every deadline you meet.
Let the prospect of losing each $1,000 motivate you to stick to the plan.
6) Perfectionism (aka, Broken Process)
I usually convince clients to launch a “lite” version of the new website with language like this: “Let’s take a phased approach and get a stripped down version of the site live as quickly as possible. We can always add to it later.”
Of course, different kinds of websites deserve different timelines. Thousands of lines of code can’t be rushed without quality suffering.
But five-, ten-, 20-page brochure sites? The best approach is launching a Lite version then iterating it.
Clients tend to agree and still drag their feet: “Lite version? Sure. But it is really important that we get our new vision statement on the website, and Bob doesn’t return from China until Friday of next week.”
The delays snowball from there.
Perfect is the enemy of done. An unlaunched site cannot pay for itself.
Until you have a new site in place generating conversions and leads, you have sunk costs: not an investment, not even a website, but a pebble in your shoe that causes pain without delivering value of any kind.
The longer you wait to go live with your site, the more opportunities you miss.
Thus, the longer you wait to go live, the more expensive your website becomes. Waiting on Bob to weigh-in so that the team can perfect that new visioning statement can become a costly decision.
Ask yourself these two questions:
- How much will the brand really suffer if you go ahead and launch a lite version of the site quickly?
- Will customers leave in droves if we use some old/imperfect/incomplete placeholder content?
It’s important to recognize that we more sensitive to our perceived flaws than customers are.
I liken this sensitivity to the high school kid on his way to prom. As he adjusts his bowtie, he notices a zit.
“What is that? Oh no!” he thinks. “How could this happen?!” With mounting anxiety, he starts working on the zit.
It turns into an angry red beacon pulsating on his forehand, and because he is now self-conscious, our protagonist mentions the zit to his date. She glances at his forehead, and shrugs.
“I probably wouldn’t have noticed it unless you drew my attention to it,” she says.
We are more conscious of our blemishes than the people whom we hope to impress. That’s why we can safely launch a lite version, even with imperfect content, and iterate quickly.
This would not be a good advice for a big brand like Coca-Cola. Public backlash is a real thing when you’re getting gobs of traffic. But most companies’ websites do not get gobs of traffic.
Only a fraction of your web visitors are true prospects, and only a fraction of a fraction might behave like this:
- Land on your new site.
- Click through several pages.
- Run across one of your blemishes.
- Notice the blemish.
- Form a negative opinion about your company.
- Leave your website and never do business with you.
Why would anyone wait to launch a perfect site if the benefits of launching a lite, imperfect site are more apparent? No one said perfectionism was logical.
Whenever possible, I persuade Wunderbar’s clients to take a phased approach to their websites. Launch a lite version quickly. Iterate quickly. Use Google Analytics and real data about people’s behavior to make decisions about what content to add or what adjustments to make.
Most people spend way too long getting a new website up, but you don’t have to be one of them. Follow these rules of thumb, and your new site will be making you money in no time:
- Collect your assets in advance.
- Collect your credentials in advance.
- Avoid design by committee, and give one person the final say.
- Don’t micromanage your developers but instead flex that decision-making muscle only for the most important decisions.
- Meet deadlines.
- Launch quickly. Iterate quickly.
What did I forget? If you think other factors contribute to delays, chime in with a comment below.
Do you want to build a profitable business you love?
Duh. Pony up that email address, and you can learn from my failures. You can laugh at my mistakes. You can envy my success at croquet, slow running, and modest bank accounts. Let’s make good money and leave the world better than we found it.
No-nonsense business advice for content writers and freelancers. Served warm with a side of dad jokes.