Our Favorite Mistakes (March 2017)

Meetup members shared some of the worst mistakes they’d made as WordPress consultants, and how to avoid repeating those mistakes in the future. Here are some examples.

Not finding out who the real stakeholders are

When talking with a prospect, ask who the decision-maker is and whether anyone else needs to sign off on the deal. (I have had clients back out of projects after talking to their spouses; in a corporation, it may be your contact’s boss or the CFO who has to approve the expenditure.)

Not checking the client’s references

Sometimes you can’t predict that someone will be a Client from Hell, but sometimes a little research would tell you. If a prospect (or subcontractor) gives you references, check them. Even if they don’t give you references, 19Google the client and the company; check them out on LinkedIn and ask any mutual connections what they’re like to work with.

Putting up with an abusive client

The mistake: not ditching them. Fire any client that yells at, blames, threatens, or harasses you in any way.

Promising something you can’t do

Tell them you’ll look into it, give yourself an hour, and see how much you can find. Delegate if it’s not appropriate for your skills. Better to make a small fee for hiring a subcontractor than to waste a lot of time and fall flat on your face.

Not Charging for Project/Client Management

Project management can take as much time as design and development–or more. Conversations with clients cost money. They should know that you’ll be billing them for calls and emails, as well as time you need to spend coordinating your team.

Not Charging for Discovery

Discovery is a time-consuming process, and when you create a detailed proposal, you give a client a blueprint that s/he could take to another developer. Discovery is consulting and a valuable service. If you charge for it, you won’t waste your time or the client’s.

Not Doing Your Own Discovery

Even if you’re brought on to a project as a subcontractor, it’s a good idea to do your own discovery session with the client. It’s possible that the person who brought you in didn’t know the right questions to ask in order to uncover potential pitfalls.

Not Tracking Your Time

Even when you charge by the project, track your time. You probably think you can work faster than you actually do. You might learn that you’re making $2/hr on what you thought was a profitable project rate.

Changing MX Records When You Shouldn’t

If it’s not clear where their MX points, FIND OUT. Clients get positively hysterical when their email doesn’t work. Moving a site to a new host may mean migrating email, which in turn requires a list of email accounts and passwords and possibly quite a bit of time. There are good reasons to recommend that your client use email hosting separate from their web hosting. One of them is that you don’t have to migrate their email if they change hosting companies. (You will need to record the existing MX records if you are changing nameservers rather than using an A or CNAME record to point the domain to the website.)

Not Making Backups (offsite) and Not Testing Backups

Check up on what’s being backed up. Even if you set up automated backups for them in the past, make sure the backups are being created and that you can restore the site from them before you make any irrevocable changes.

Developing on the Production Server

Especially if you haven’t made backups! You don’t want visitors, or even your client, to see the site when you just messed something up. Use a local development environment or at least a separate install on a subdomain.

Not Getting All the Credentials Before You Start

While you might not know for certain that you’re going to need to log on to the client’s domain registrar, hosting cPanel, Google Analytics, FTP server, etc. as well as their WordPress site, it’s better to have this information and not need it than to have to call the client in a panic because you messed something up and don’t have the access you need to fix it. (Especially if you are guilty of developing on the production server.) If a client doesn’t have a WordPress.com account (for instance), either create a forwarder from their domain email or a throwaway Gmail account you can use in order to set things up. (When the project is finished, point the forwarder to the client’s email.)

Forgetting to turn on the search engines

You might want to make use of this pre-launch checklist from WPMUDEV or this checklist for launching a Genesis project to avoid embarrassing oversights like continuing to block search engines when you promised improved SEO.

Not mapping old URLs

Unless you are keeping exactly the same page/permalink structure from the old site to the new one, you need to create a spreadsheet with the URLs of all pages on the old site so that you can map them to their destinations on the new site. This is the basis of your 301 Redirects. You can copy the appropriate cells into the Batch RewriteRule Generator and then have them ready to put in your .htaccess file. Without the appropriate redirects (whether you use .htaccess, a plugin like Redirection or Simple 301 Redirects, or a tool provided by your hosting company, redirects preserve the incoming links and Google ranking of the pages you move.

Assuming Your Client Is as Technical as They Want You to Think They Are

“This should be easy,” or “This should only take you an hour,” are big red flags. Also, clients use words they don’t understand. You might give them exactly what they asked for, only to discover they meant something else entirely. Ask clarifying questions. One of the best is “Why do you want this feature?”

Assuming Your Client (or Subcontractor) Understands What You’re Talking About

Ask them to paraphrase what you’ve told them in their own words. People hate to look ignorant, but pretending to understand something you don’t leads to unfortunate (and avoidable) misunderstandings.