WordPress is a wonderful technology, but most small business website owners are not having wonderful experiences with it.

After more than five years of doing WordPress development full-time, one thing keeps coming back to me: just how bad the average person’s experience is having a small business website built in WordPress.

WordPress is a wonderful technology, but most small business website owners are not having wonderful experiences with it. In this article, I’ll explain why not, and present what I hope could be a solution.

How to Use This Article

This article can be useful for both web developers and website clients:

For Developers (People Who Build Small Business WordPress Websites)

I want this article to be a catalyst toward a better experience in WordPress for small-business clients—and developers. If you’re a WordPress developer (or, more generally, someone who builds or works on WordPress websites for others), I want your help:

For Clients (People Who Need a Small Business Website)

If you’re looking to have a website built for a small business, you need to understand two things:

Unless the project is small and simple enough for Squarespace, you’re probably going to want to have your site built in WordPress. Many, perhaps most, small business WordPress projects go badly, so if you’re not careful and informed there’s a very high chance you’ll have a bad experience.

This article can help you become careful and informed. You should:

Read the entirety of the next section, which identifies and explains the problems small-business website clients like you often face. Read the Small-Business WordPress Developer Code of Honor. It’s most important to read the titles; you can skim the content. Every one of these things is what a good web developer (specifically, a good WordPress developer) does. The opposite of every one of these things is what a bad developer does, and none of them are theoretical: there are many both good and bad developers for each item listed in the code. Read and engage with the final section, Next Steps for the Honor Code, for details on how it can be actually implemented in the real world, how you can help, and why that would benefit everyone involved.

Who’s Suffering: Small Business WordPress Website Clients

Small business website clients tend to suffer the largest gap between what WordPress can be, and how it’s implemented on their own projects.

WordPress can be great for lots of things. But an individual’s experience having a WordPress site developed may be anywhere from wonderful to awful, even for things that the software itself is good for.

In my experience, small business website clients tend to suffer the largest average gap between what WordPress can be, and how they experience it implemented on their own projects.

By “small business website client,” I mean almost anybody having a WordPress site built by a third party, except for the large, well-funded organizations—corporations, government and educational institutions, and so on—that premier agencies like 10Up and Human Made typically service. Those organizations are implementing WordPress in very large projects, and whatever the shortcomings of the software itself may be in that setting, they’re paying for outstanding, fully-loaded help.

For most other people, unfortunately, quality is a toss-up.

The Problems Small-Business Clients Experience in WordPress

When I first meet small-business clients, they’re often at the end of their ropes.

When I first meet most of my clients, they’re generally not launching their small business website from scratch—they’re trying to carry an existing project or site forward. Almost all of them come to me at least one of the following issues:

Project has taken vast amounts of money and time and isn’t close to working properly

Client is attempting to rebuild after relationship with prior developer ended on bad terms

Site has urgent issues and current developer takes weeks to respond, or has stopped responding to communication entirely

Project ruined long-standing site’s SEO

Site is almost unusable because of horrible hosting

Site is almost unusable because of horrible theme and/or plugins implemented by non-specialist billing self as developer

Client took “You don’t need a developer” promise by theme/hosting/etc. seriously, has built one-tenth of a badly functioning WordPress site, and is exhausted and stuck

Project’s underlying business plan has no chance of succeeding

In other words, people aren’t coming in happy. They’re desperate, turned-around, way past any original timeline and budget estimates, they’ve been told thirty things by twenty people and disappointed repeatedly by professionals they trusted. They’re at the end of their ropes.

If you don’t know the feeling—if you haven’t tried contracting out a small business WordPress website without technical knowledge—then maybe an analogy will help put the experience into familiar terms.

What Getting a Small Business WordPress Website Feels Like

If “WordPress” were “bicycles,” the average small-business client looking for a bicycle would buy what turns out to be a unicycle with a tricycle wheel nailed to it.

If “WordPress” were “bicycles,” the average small-business client looking for a bicycle would buy what turns out to be a unicycle with a tricycle wheel nailed to it.

The “bicycle” costs $29, and you buy it from a giant website that dominates search engines for anything bicycle-related. That site promises you that you don’t need a technician to get set up with your new “bicycle”; but you absolutely do, and the technician costs a seemingly random amount between $300 and $9,000.

It’s also seemingly random whether the technician is qualified: most of the time, he is not, and even after paying him far more than you initially agreed to, it’s most likely that you still don’t have a working bicycle.

You may go through numerous technicians over many months, each seeming to make progress in some areas while falling short in others, continually costing you more time and money.

If you ever do run into a qualified technician, she will most likely tell you a few things:

First, you made a huge number of very costly mistakes in the very moment you bought anything. Some of these mistakes look obvious in retrospect (like being duped into buying a “bicycle” that is actually a clumsily modified unicycle), but most of them could not possibly have been known to you as a consumer. For example, the brand of pedals your purchase came with have—for no good reason—plastic ball bearings inside them instead of metal ones, which makes them almost unusuable.

Second, as you suspected, the previous technicians didn’t actually understand bicycle assembly or repair. They were in fact pretending to know how to do their job, with the aid of numerous “add-ons” (some of which were free, some of which you paid for) that, as it turns out, were mostly attempts to compensate for gaping holes in their own knowledge. For instance, your tire is flat, and because your previous technician didn’t know how to inflate a tire—but did know that a bicycle should “go fast”—he installed a large, bulky sail that drapes down and gets caught in the chain, making normal use of the bicycle almost impossible.

We could develop the analogy even further, but the overall experience should be clear: the process of having a WordPress website built, for far too many small-business clients, is bafflingly, infuriatingly broken.

Let’s look at why.

Why Small-Business WordPress Clients are Suffering

Small-business WordPress website development is basically the perfect storm for a bad customer experience.

Getting a small-business WordPress website built is so much more chaotic on average than buying a bike or a fridge, or even having other skilled work (like plumbing or electrical work) done. Why is it like this?

I’ve thought, and written, about this a lot. The overall conclusion I’ve drawn is that small-business WordPress website development is basically the perfect storm for a bad customer experience:

WordPress development is a jungle of almost 100% unlicensed practitioners with no oversight of any kind. You’re a WordPress developer if you say you are and can get clients—your qualifications beyond that are a toss-up.

Clients are at their most ignorant when they’re buying websites. More so than with most other kinds of purchases, clients who want “a website” often have an elaborately unrealistic understanding of what a website is, how it should work, how it should relate to anything else on the internet, whether and how to actively market it, what broader value it can provide a business, what experts (if any) are needed to set it up, how much an expert’s help should cost, and how to tell if a given “expert” is any good. Very few clients know the extent of their own ignorance, and so the industry as a whole—especially in areas like WordPress themes and hosting—is built around it.

Good information is almost impossible for a nontechnical person to obtain. Depending on the question, the truth often comes in technical language (for example, Stack Overflow posts) that requires a huge body of specialist knowledge to properly grasp and apply; or the truth may be buried under various kinds of lies told within a free-market system built on consumer ignorance, as when a client Googles for theme or hosting recommendations. As a result, even clients who are motivated to reduce their ignorance are very unlikely to be able to do so.

For an average small business client looking to have a WordPress website built on the open market, it’s chaos.

For an average small business client looking to have a WordPress website built on the open market, it’s chaos. Everyone is saying random, incompatible things, and everyone wants money. The truth is out there somewhere, but it is literally impossible to obtain. And meanwhile, we need a website.

What WordPress Developers Can Do to Improve the Small-Business Client Experience

Small business website clients, as a whole, are vulnerable.

Small business website clients, as a whole, are vulnerable. Their lack of knowledge makes them easy to exploit, and that’s what the marketplace, by and large, is doing.

It’s actually not that different from feudal Europe or Japan. You have:

A large population of vulnerable people. That’s the populations of those countries in those examples, and small-business website clients in this one. A small population of people with specialized tools and knowledge that they’re free to use either for good or for evil, with basically no repercussions from the broader environment. That’s knights and samurai in those examples, and WordPress developers (and “developers”) in this one.

Now, what do you do to rein in the people with the specialized tools?

That’s right:

We Need an Honor Code

Because the small-business website marketplace cannot effectively police itself, there needs to be an honor code among website developers to watch out for clients’ best interests.

An honor code is a voluntary commitment that people with special skills or privileges make. The commitment is to use those skills or privileges for good, as defined by the code itself.

The most famous honor codes in history—bushido in Japan, chivalry in Europe—come from feudal societies whose basic dynamics are fairly similar to the small-business website marketplace in the ways we’ve outlined.

Like those societies, this marketplace cannot police itself effectively enough to ensure that clients aren’t mistreated in large numbers. There needs to be an honor code among the people who service those clients, to watch out for their best interests. And we can start out with a code among developers within WordPress, the largest and best technology for most small-business websites.

I’ve Made One!

I’ve made a first version of the code I think we need: a Small-Business WordPress Developer Code of Honor.

I really want your feedback on it (see final section), but I also feel quite good about it as a first draft. It does the best I can to synthesize the most common and important practices that separate WordPress development done right from the bad results that so many small-business clients are seeing.

The Honor Code itself is available below, with detailed explanations of each point. To see the Honor Code at-a-glance with no explanations, here’s a one-page PDF download, and here’s a .md file on GitHub.

The Small-Business WordPress Developer Code of Honor

Download as a single-page PDF | View on GitHub

Current Honor Code version is 1.0

Overriding Principles

These principles form the general worldview and ethical foundation that the individual pieces of the honor code are built on. Anything in the more detailed sections below this one should be traceable back to one or more of these principles.

The purpose of my work is to accomplish my clients’ real-world goals.

People purchase websites, and pay WordPress developers, in pursuit of real-life goals.

Like money or a good credit score, a website is not an end in itself. People get websites because they think those websites will help them achieve one or more real-life goals. When they pay you, a WordPress developer, to help them with their website, they’re really paying in pursuit of those goals.

In other words, your job as a WordPress developer is to use your technical knowledge to improve people’s lives in the ways they’re asking you for help with.

This is obvious written on the page, but it can be easy to lose sight of:

Have I asked my client what her goal is with this project? Do I know whether or not her goal is realistic, and have I shared that understanding with the client?

Am I checking my own advice, and evaluating my client’s proposals, against a clear understanding of the goals of the project?

Why am I accepting money to build a feature that my client thinks she wants, but that I know cannot help her reach her goal?

What if a WordPress website is clearly the wrong path to my client’s goal? Do I see it as part of my job to tell her a better route (whether or not that route involves me making money)?

Our work exists to improve our clients’ lives, in ways that are specific to the project, and that we should always understand clearly.

We do our work to improve our clients’ lives, in ways that are specific to the project, and that we should always understand clearly and never lose sight of.

And if our work cannot realistically help our clients in the ways they’re hoping for, it’s our responsibility to tell them.

I will hold myself accountable for the knowledge and skills necessary to do my work well.

It falls on developers ourselves to ensure we’re qualified to do our job.

However good our motivations, we cannot be the source of help our clients are expecting (and paying!) us to be, if we don’t know our own job.

Nobody’s really going to check up on us, either: our clients can’t tell good developers from bad ones, except after weeks or months of poor results, and there’s no real external source of accountability we can be held to: no standardized test, no Better Business Bureau, no Yelp reviews.

And so it falls on us to ensure we’re qualified to do our job. We should take this seriously, and embody the full range of competencies that “WordPress developer” describes. It’s the right thing to do, because our training is what allows us to help clients meet their goals.

Of course, everybody knows some things, and nobody knows everything. (In general, people, especially beginners, overestimate our knowledge, because we don’t know what we don’t know.) And, obviously, we can’t just magically wish to be mid-career if we’re starting out. So there’s a question of threshholds: how much does a developer need to know to do right by her clients?

There’s a section of this document outlining the concrete list of skills that make up a “WordPress developer.” More generally, it’s a question of attitude: developers will always have more or less knowledge and experience, but each developer’s attitude should always be one of continuous responsibility for learning what’s needed to do the job properly.

I will never use my clients’ lack of knowledge against their best interest.

Clients’ lack of knowledge must always be managed with their best interest in mind.

This is the crux of working with clients who can’t easily evaluate our qualifications, the quality of our work, or the truth of statements we make. That gap in knowledge must always be managed with the client’s best interest in mind.

There are all kinds of ways that a developer can misuse a small-business client’s lack of knowledge:

Offering an inferior product based on false pretenses.

Using technobabble to impress clients into making decisions without careful consideration.

Billing based on the limit of the client’s budget, not the actual complexity of the project.

Using jargon to make costly mistakes we made seem like they “just happened” for mysterious, external reasons.

And so on. All these dirty tricks, and their permutations, and the many others like them, are what we refrain from when we take our clients’ best interest as the bedrock of our interactions with them.

I will not mislead my clients.

Your communication with your clients should be materially true, complete, and should enable them to make good decisions.

This is one way of emphasizing the general principle of working with the client’s best interest in mind.

Obviously, you don’t have to explain the technical details of everything to your clients. They don’t need to know that the custom order form you built for them broke because WooCommerce changed the array key names in its $product->get_available_variations() function. You can just tell them “It was an issue related to a recent WooCommerce update, and I believe it’s fixed now.”

But the way you communicate them (including how you summarize information) should always be guided by three general questions:

Is what you communicate to your clients materially true? Does it summarize or simplify the truth, as opposed to misinformation? Is your communication to your clients complete? Have you made sure not to omit important information that would affect their ability to understand, and make decisions based on, the key truths of the situation? Overall, does your communication to clients give them the understanding they need to make intelligent decisions in pursuit of their own goals?

Your communications with your clients should satisfy all three of these criteria. If not, you’re misleading them—whether you’re selling a busted theme-plus-proprietary-page-builder on false pretenses (violates #1), or explaining poor SEO performance by rambling on about “Google’s algorithm” while omitting that you only remembered to 301 redirect old permalinks last night (violates #2), or simply letting your clients continue paying you to assemble an Airbnb clone in WordPress even though that makes no technical or strategic sense (violates #3).

I will not misrepresent my own knowledge.

Your clients should clearly understand what you’re capable of, including the boundaries of your expertise.

This is obviously already captured under “I will not mislead my clients,” but it bears emphasizing as a separate commitment: Your clients should clearly understand what you’re capable of, including the boundaries of your expertise.

If the site’s very slow, and you don’t understand anything about page speed except how to throw up a free caching plugin, your clients should know that: then they can pay someone else to look into the issue. If they think that you, the “expert,” did everything that could be done, then they’re stuck with a site that’s not meeting their needs until someone tells them the truth way down the line—all because you either didn’t know or wouldn’t communicate the boundaries of your own knowledge.

The broader point is that you need to educate your clients on both the roles that you do and don’t fill within the project. They need to know why a designer matters for achieving their project’s goals, and an SEO, and a digital marketer—and they need to know that you are a developer but not a designer, that you do understand SEO well enough for their needs but not digital marketing, and so on.

If you let your clients continue to think of you as a vague “web expert,” they’ll pay you for bad work instead of finding the right fit for their actual needs. And more broadly, if you let them persist with a fuzzy understanding of the needs of their own project, they can’t make good decisions. It’s your job to educate them in these ways.

General Approach to Projects

These items flow from the principles above, and shape the practical way we engage with clients: the style in which we answer questions, describe our own abilities, and so on.

I will offer solutions within the context of the real-world goals of the project.

It’s easy to let client momentum and confusion drag a project off-course, and this item is a commitment not to do that.

This item is a consequence of our commitment to always work to promote our clients’ real-world goals. It’s often extremely easy to let client momentum and confusion drag a conversation—or even a whole project—off-course, and this item is a commitment not to do that.

Your technical advice should always take into account the context of both the project and the conversation, including the real-world goals and level of knowledge of the person you’re communicating with.

If your client asks you whether Easy Digital Downloads integrates with WooCommerce, your answer shouldn’t be “Yes, we can make that work,” but rather, “Can you explain why you want that? Those two plugins do very similar things.”

If your client asks you “What’s the best way to build a social network?” you shouldn’t simply say “You’d want to build it from scratch in something like Python,” but rather, “What features of a social network do you think will be helpful for your law firm’s website, and is there another way to get just those features?”

And so on. In sum, your communication should be identifying and filling in key gaps in knowledge with the purpose of helping the client make good decisions, and the solutions you propose should have the client’s best interest at heart. You shouldn’t be just answering poorly thought-through questions head-on, and building dead-end features because the client asked for them.

I will know, and communicate, the boundaries of my own competencies.

In addition to back-end development and front-end development, a WordPress professional’s work touches frequently on the following areas, among others:

SEO

Web design

Graphic design and branding

Digital marketing

Server and database administration

Digital security

Digital strategy and entrepreneurship

Law

You need to tell your clients exactly what you are, and aren’t, professional-caliber at, and to proactively help them identify project needs that fall outside of what you do.

You are not an expert in all these areas. Many of your small-business clients won’t know that, though: they’re unaware that most of these areas exist, or that there are professionals who focus in them.

As a result, your small-business clients will naturally ask you, the “web expert,” to extend beyond the boundaries of your own competencies on their projects. If you’re making logos in MS Paint and offering legal advice backed by Google, you’re doing it wrong.

You need to tell your clients exactly what you are, and aren’t, professional-caliber at, and you need to proactively help them identify project needs that fall outside of what you do. Most of your clients will need help from additional contractors (most commonly designers, SEOs, and digital marketers) to meet their real-world goals, and you need to tell them that. Ideally, you’ll help them find the additional contractors as well.

This can be a win-win for everybody: you find experts in each of these fields that become trusted networks of mutual referrals, and your clients have a range of vetted professionals they can turn to for each of their needs. The most important thing is that you take the proactive step of matching the client’s understanding of your role to reality.

Client Relationships

I will treat my clients with respect.

More than a specific set of rules, this item is a commitment to work on your interpersonal dynamic with clients, and not to force them to accept your rudeness as part of the cost of doing business.

This item refers most specifically to respectful communication. The broader respect you have for your clients’ time, money, and humanity is captured above by your commitment to take their best interests and real-life goals to heart. But that still gives you leeway to be a jerk on the phone, for example.

This item is also, in a sense, intentionally vague. What does treating your clients with respect look like? You should do that. Does that mean dialing back your tech-bro persona? Not cutting in when you think you know where a question is going? Rephrasing questions so that they don’t accuse the listener of lacking important knowledge?

The best source of feedback here will be your clients: what behaviors of yours seem, more often than they should, to cause interpersonal tensions? What can you do to shift them?

If you’re decent at self-reflection, the Golden Rule can be an amazing mirror, too. Would I want someone to talk to me this way? If the honest, first-thought-best-thought answer is no, you should take another look at the behavior.

More than a specific set of rules, this item is a commitment to work on your interpersonal dynamic with clients, and not to force them to accept your rudeness as part of the cost of doing business.

I will offer, and adhere to, clear timeframes in which the client can expect a response from me.

A lack of developer responsiveness may be the single most common thing that small business website clients have to suffer through.

In my experience, a lack of developer responsiveness may be the single most common thing that small business website clients have to suffer through.

Most clients are petrified that their site will break and they’ll have no one to call, and that certainly is a nightmare scenario that can happen. However, what’s probably more common is that all communication takes way too long: I asked about this problem on a Monday, and I heard nothing until the following Thursday when the developer wrote “Fixed! took 5 minutes”—but I was really worried in the meantime.

At the outset of any client project, you need to set, and adhere to, clear expectations around how quickly you’ll respond to:

Client communications, such as calls, texts, or emails.

Requests for information, clarification, or updates.

Feedback on progress through the project, such as bug reports or design feedback.

Ongoing support needs post-launch if you provide those, including emergency situations (“we just launched our new product line and the site is down”).

This doesn’t have to be some sort of elaborate contract; it can be as simple as “I’ll always respond within 48 hours, and if there’s a live-site-breaking problem you can text me and I’ll respond as soon as I can get clear of what I’m doing.” The trick is that you then have to uphold these commitments, potentially for years if the client relationship is long-lasting.

One side note here is that it’s important to have some sort of backup plan for vacations and other life events. You can’t be the single line of defense for dozens of client sites if you’re going to be totally unplugged in the Amazon for three weeks. You need to find another developer you trust as a go-to for your clients, and put the systems in place for your clients to contact them if urgent needs arise in your absence.

I will communicate steadily and proactively about the project’s cost and progress toward completion.

The client should at no point be left guessing about—or afraid to ask—how much the project will cost, and when it’ll be completed.

In other words, the client should at no point be left guessing about—or afraid to ask—how much the project will cost, and when it’ll be completed.

If you’re getting “Update…?” or “Just checking in” emails from your clients, you’re doing this wrong, and if they’re having to muster up the courage to ask whether the project is still within their budget you’re doing it wrong too.

Some specific behaviors satisfy this commitment:

At the outset of the project, I will create a schedule and system for checking in with the client on the project’s budget and timeline, and I’ll adhere to that system.

When I become aware that the project will exceed its budget or pass its deadline, I will inform the client.

The goal here is that your clients should always be able to make good decisions, based on accurate information about how the project is progressing relative to its budget and deadline. Any other situation obviously goes against their best interest.

I will not dissolve, or become unavailable for, client relationships without proactively informing my clients.

One of the biggest setbacks many of my clients have experienced—and one of their biggest fears—is a developer simply cutting communication. That commonly looks a lot of ways:

Simple ghosting, where a developer is just never heard from again.

Longer and longer response times as the developer first takes a long backpacking vacation, then loses his computer, and so on, basically “daring” the client to move on without saying so directly.

Some sort of blowup leading to the sudden termination of the professional relationship—often leading to a scary scramble to find a new developer who can change passwords and recover files, conducted in the shadow of all the things the client fears the previous developer might do to the site in the meantime.

Anytime you want to dissolve an existing client relationship, it needs to be done with the client’s best interest in mind.

Anytime you want to dissolve or otherwise transition out of an existing client relationship, it needs to be done with the client’s best interest in mind. That means giving the client enough time to find qualified help to replace you, and easing the transition to the new help with credentials, a project brief, and so on.

Otherwise, you’re still “on the hook” with your current client, and you should respond to their communications subject to the timeliness guidelines discussed above.

WordPress Development Practices

This section describes specific ways that a WordPress developer should behave. The commitments in this section take the broader principles from earlier sections, and apply them to the specific realities of the WordPress marketplace and software ecosystem.

I will not market myself as a “WordPress developer” without the qualifications of that term.

It’s on us to be who we claim we are.

The truth is that small business website clients looking for WordPress help are not going to be in a position to evaluate the professionals they contact. It’s on us to be who we claim we are.

That doesn’t mean that we all need to be the world’s most experienced WordPress developers—and, of course, much of the journey to being a full-fledged WordPress developer involves offering help to clients before our skills are “perfect.”

Still, there are a few bedrock requirements without which we’re honestly doing wrong by our clients if they believe we’re the WordPress developers who can make their projects work. They include:

Knowledge of PHP.

If you can’t write and understand PHP, you’re not a WordPress developer.

If you can’t write and understand PHP, you’re not a WordPress developer.

I don’t say that to sound dramatic, or to impose barriers to entry or an elitist mindset. The truth is that without PHP, there are vast numbers of problems in WordPress you can’t solve—basically anything below the surface level that your clients themselves could YouTube about. It’s as serious, or more, as a plumber who didn’t own a wrench or understand how pipes work.

You also can’t find the best solutions for most needs beyond the simplest and most routine. You’ll be trapped into using tools for non-technicians, and all these tools come with tradeoffs, some mostly light, some crushing.

The bottom-line truth is that your clients will not benefit from working exclusively with a professional billing himself or herself as a WordPress “developer,” but who doesn’t speak the language of the software.

PHP is massively useful and there’s never a wrong time to start learning.

I do know that PHP is a big barrier to many. There are all kinds of education resources on the web (we recorded a quick getting-started video on PHP in our “learn WordPress development” course Up and Running). PHP is massively useful and there’s never a wrong time to start learning.

It’s also possible to do helpful, high-quality client work as a WordPress implementer without PHP, but you should always have steady access to and guidance from a PHP-aware developer who can help you do things the right way—even when that requires PHP—and who can fix things when they break.

More generally, we should understand that charging small business website clients $100 or more per hour out-of-pocket is a privilege, based on trust. We need to do our end to uphold that trust, and that includes knowing PHP if we say we’re WordPress developers.

Knowledge of WordPress as a software system.

Knowing WordPress’s systems is what enables developers to do our job properly.

WordPress is not just “PHP”; it’s an enormous software package mostly written in PHP. You could know the heck out of PHP and still not know how (or why) to hook into init , or write a custom WP_Query .

A WordPress developer does know these things—because, again, they’re what enables us to do our job properly.

You don’t need to be at the level of contributing heavily to WordPress Core, or writing premium commercial plugins, or pioneering crazy-intricate uses of WordPress. You just need to know the proper use of WordPress’s core systems, and have enough hands-on experience to be able to use them properly for your small business website clients.

If you want to know what systems make the list, the Up and Running table of contents is our best in-one-place guide. Everything on that list will be important at some point in a WordPress developer’s work.

How much exposure to these systems is needed? I’d estimate that a year of diligent, PHP-informed learning would be enough to move from “junior developer” to “developer,” although my own skills certainly continue to develop and solidify five or six years in.

Knowledge of proper development practices.

When people start out building websites, they are a danger to the websites. This is because of practices like:

Cowboy-coding on live sites.

Failing to use Git and other forms of version control.

Failing to take site backups before major changes.

Editing theme and plugin files directly in wp-admin without FTP access should things go wrong.

without FTP access should things go wrong. Failing to back up locally saved project files to the cloud.

Failing to update WordPress, themes, and plugins.

Choosing insecure passwords.

Insecurely storing or sharing credentials.

If you mash up a client’s database or lose critical files, it’s on you, whatever your other skills and abilities.

It takes a good amount of experience to know what’s necessary in these areas, and that knowledge is a crucial part of being a WordPress developer. If you mash up a client’s database or lose critical files when your laptop goes down, it’s on you, whatever your other skills and abilities.

Issues with development practices should not affect the viability of clients’ sites and businesses, and knowing how to ensure that they don’t is a core skill of a WordPress developer.

Fundamental knowledge of SEO.

SEO is the main opportunity a WordPress developer has to make business-destroying mistakes that no one can fix.

Understanding SEO is part of a WordPress developer’s job description, because SEO is the main opportunity a developer has to make business-destroying mistakes that no one can fix. Websites often have backups if you delete the whole database or filesystem. The site’s SEO has no backup, and it’s also not something you can “rebuild,” except over months and years.

You do not have to be an SEO professional, capable of running campaigns to improve a site’s performance in search. What you do need to have is a basic understanding and instinct for how SEO works—things like:

How to understand a site’s current position in search, and what a redesign could do to it.

How, when, and why to redirect permalinks.

When and why it’s dangerous to change a page’s content or the way that content is presented.

SEO traps not to fall into, like leaving “Discourage Search Engines” enabled on a live site.

SEO-ignorant WordPress developers are a danger to their clients.

Notice what’s not on that list: “How to install Yoast.” Yoast is great, but it will do precisely nothing to stop you from ruining a site’s SEO. If you don’t know why that’s the case, the truth is that you have no business being the buck-stops-here technical person on a WordPress web project.

To do right by your clients, your knowledge of SEO needs to be good enough that you never make mistakes that take a site’s SEO significantly backward. Unfortunately, that takes a pretty solid understanding of the topic.

There’s no alternative, though: SEO-ignorant WordPress developers are a danger to their clients.

I will take seriously, and hold myself accountable for investigating, the quality of the third-party software I use within WordPress.

A WordPress developer should choose themes and plugins that do their job without degrading the overall quality of the software environment.

By “third-party software,” I mean mostly themes and plugins.

A WordPress developer should choose themes and plugins that do their intended job, without degrading the overall quality of the software environment they’re in.

To do this right requires a solid understanding of what themes and plugins are for, and what quality looks like in a WordPress context.

Having—and continually refining—this understanding is an indispensable part of being a WordPress developer: a huge proprtion of the ecosystem is slicky marketed but low-quality, and it’s your job to know how to navigate your small business clients to the right solutions for them.

Defensible theme choices.

The themes you choose should reflect the proper role of a theme, by not trying to do a developer’s job.

Most WordPress themes are horrible. It’s not generally that they do the right thing badly, it’s that they do the wrong thing well.

The largest WordPress theme marketplaces—ThemeForest, Elegant Themes, and a couple of others—sell directly to WordPress implementers and end users. The pitch is what those people want to hear:

Get the website you’ve always dreamed of for $49!

You can customize it to do anything!

You don’t need an expert to set it up!

These are all lies, and that’s what the average WordPress theme is: a lie, sold directly to a small business website client, or to another non-developer in a helping role.

The truth is that WordPress is simply too complicated for anybody but a developer to set up properly. The themes you choose should reflect this, by not trying to do a developer’s job.

Our articles on Theme Creep are still a good guide to what this means in practice. A theme should be pretty much for presentation (display) only. Everything else you do yourself.

In other words, if your client needs a real estate listing site and your first impulse is to look for a real estate listing theme (plenty of which exist!), then you’re coming at WordPress development in absolutely the wrong way and your client is in for a lot of heartbreak.

If you want some good, sturdy theme recommendations, here are a few:

The Underscores (_s) and Understrap starter themes

Storefront, for WooCommerce projects

Some themes by small third-party vendors, typically not on ThemeForest

If you choose themes that do try to do your job, what happens is: first, they fail; and second, they fail in such a way that it becomes almost impossible to do the project properly. You shouldn’t be using these kinds of themes as a WordPress developer, and you should understand why not.

Defensible plugin choices.

A few plugins are never the right choice. The ones that come to mind include:

WPBakery Page Builder, formerly Visual Composer (the worst major page builder in WordPress)

Revolution Slider (security vulnerabilities, sliders are mosty bad anyway)

Bad random plugins that do something (forms, caching) that there are already good first choices for

A WordPress developer should have a good reason, that actually stands up to scrutiny, for using every plugin he or she does.

Most plugins, however, have a proper use case. The question is: what are the tradeoffs you accept when you install a given plugin, and is there a better route to the same end goal?

Too many WordPress sites have 40 or 50 plugins, many of them vastly overcomplicated hacks for things a developer should just know how to do. An example would be an enormous, heavy, premium “gallery” plugin for what is really just a simple three-column image grid on a single page, best addressed with 20 lines of CSS and 10 of PHP.

The point is that a WordPress developer should have a good reason, that actually stands up to scrutiny, for using every plugin he or she does.

Of all the things in the job description, this is one that takes the longest to learn, because it takes so long to get exposed to the use cases for most helpful plugins, and because the plugin ecosystem itself is always changing. So this is a neverending journey, but a WordPress developer should be on it.

My use of third-party software will not have the purpose of compensating for gaps in my knowledge.

WordPress developers should not implement themes and plugins to hand-wave at topic areas they don’t understand.

This ties into, and, in a way, summarizes the sections on themes and plugins above.

You should use themes and plugins (and other software solutions, such as SaaS products) in ways that are the correct solution for the client need at hand. Being able to do that is a function of your own knowledge.

What a WordPress developer should not do is implement themes and plugins to hand-wave at topic areas you don’t understand:

A “marketplace theme” for a client trying to set up a multi-vendor marketplace (doable but not generally a great idea in WordPress, definitely not a theme’s business).

A security plugin “for security,” with no further depth on what WordPress security is and how to do the basics properly.

Yoast “for SEO,” with no further depth on what SEO is or what Yoast does.

A caching plugin “for speed,” with no further depth on why the site’s slow in the first place (giant images? insanely inefficient queries? tons of render-blocking resources?).

Third-party software is a tool to help you do your job better—not a crutch to compensate for holes in your knowledge.

My hosting recommendations for my clients will stand up to reasoned scrutiny.

Hosting is really important to get right for your clients, because a bad host will put the entire project on a shaky foundation.

The hosting space is the most lucrative part of the WordPress ecosystem, and the truth on hosting quality is also the most distorted by various kinds of marketing, especially direct-to-consumer advertising and aggressive affiliate programs.

Hosting is also really important to get right for your small business website clients, because a bad host will put a site on a shaky foundation that can make every other piece of the project slow, expensive, and frustrating.

You can read our attempts to bring clarity to the space, but the bottom line is that you yourself need to take the time to cut through the noise.

As a preliminary statement: If you are recommending a host owned by EIG (that includes Bluehost, HostGator, and many others), you are setting your clients up for failure. Hosting owned by GoDaddy is slightly more defensible, but still probably not the best answer. If you’re recommending SiteGround, A2, Flywheel, Pantheon, WP Engine, Pagely or others, it’s likelier that you’ve made an intelligent choice.

It’s important how you choose. You should talk to developers about what they use, ask for and read real opinions from real people, and slowly come to an idea of who’s respected in the space. You should not have seen a TV ad for your host, or clicked the top result for “best WordPress hosting,” which is going to be purely an ordered ranking of the top affiliate commissions.

I will not use WordPress for projects that are bad fits for the software.

WordPress is for some things, and it’s not for others. You should only use it for the things it’s for.

WordPress is for some things, and it’s not for others. You should only use it for the things it’s for.

Even if a client contacts you believing he needs a WordPress site, you should be ready to tell him to find another solution—from Squarespace to Node.js+React.js—if that’s the right answer for the project.

Of course, being able to give confident recommendations outside WordPress entails a fair amount of familiarity with external technologies. That’s very nice to have, but not necessary to be a small-business WordPress website developer.

What is necessary is a clear understanding of what WordPress is good for, and why—and the willingness to help your clients by telling them not to use WordPress when that’s the correct advice.

Billing Practices

These are nuts-and-bolts principles for doing right by clients on the financial side of your work. The single word “transparency” could cover almost everything in this section, but the specific ways that transparency is often needed in small-business website projects are worth teasing out and committing to.

I will not outsource labor without informing the client.

“Secret outsourcing” is unacceptable.

I’ve recently had a number of new clients ask me, point-blank, if I’ll be doing the work myself or outsourcing it. They’ve obviously had some bad experiences in this area.

“Outsourcing” most immediately brings to mind foreign labor, but outsourcing could also include hiring a local designer, or an SEO, or a junior developer who works for a cheaper rate, or even a stand-in “senior developer” to fill in gaps in your knowledge.

There’s nothing wrong with any of this—in fact, our commitment to know the boundaries of our own competencies demands some amount of outsourcing on most real-world projects. The problem is if you hide that you’re doing it from the client. “Secret outsourcing” is a no-no.

I don’t think you need to tell the client everytime someone gives you some good advice or a tip that helps you do your work. But if you’ve let your client (through active deceit or by omitting the truth) into think that you, personally, are handling a bunch of elements of the project that you’re actually not, it’s a recipe for confusion. Consider:

If something goes wrong, your client will think you understand how to fix it when you may not.

If the person who really did the work is unavailable when it needs fixed or extended, you may find yourself in a bind for reasons you can’t comfortably explain to the client.

If the subcontractor ends up doing subpar work (say you “did” some SEO work and the site dropped in the rankings), you’re on the hook for it and you may not know how to make it better.

No need to belabor the point. Your client should know enough about who’s on the project to make good, confident, well-informed decisions, and to ask you any question about the project without you having to hide parts of the truth.

I will track my time and bill for the tracked amount.

The billable time you spend engaged on a project should be rigorously, objectively, and correctly tracked.

There’s not too much to say here. As far as I know, the great majority of small-business WordPress projects are billed hourly, and for these projects you need to use rigorous time tracking. If you worked 44 minutes, that’s what should be tracked. The alternative is that you go back later and estimate how long you worked, and that’s bad. If you think you worked an hour, you’re ripping off your client. If you think you worked a half hour, you’re ripping off yourself. Either way, it’s a problem, and one with a very simple solution: learn how to use Toggl, or something like it.

This isn’t to say that you can’t round your billing to the nearest 15 minutes, half hour, hour, day, or whatever. It simply means that what you round—the billable time you spent engaged on the project—should be rigorously, objectively, and correctly tracked.

Obviously, this specific guideline doesn’t apply to flat-bid projects, or to developers that use value-based pricing. (I’m pretty skeptical that many developers consistently make value-based pricing work for small business websites, but I could be wrong. If so, I’d love to hear from you in the comments!) Whatever your pricing structure, the broader principle here is that your billing should be tied clearly and transparently to ways the client has agreed to pay.

I will only bill for time that the client is aware I’m billing for.

This specifically refers to all the “gray areas” in client communications that could be considered either as overhead or as billable work. Some of these include:

Discussions within a project on broadening out the project’s scope. Should you charge your clients for the 45-minute conversation on adding an online store that got them excited about WooCommerce?

Bugfixes for bugs you caused. A month in, the client notices the nav menu isn’t right on mobile phones narrower than 360px thanks to some incomplete breakpoints in your CSS. Do you bill for the half hour it takes to fix?

Advice. Your clients love the about-to-launch current site so much that they call a meeting to discuss their idea for an awesome mobile app/social network that maybe you can help them with. Do you bill for the 40 minutes it takes to gently dissuade them?

Your clients should know whether or not you’re billing for “gray area” time.

You don’t have to ask your client’s permission to bill for touching code or fixing bugs. But if you want to bill for anything in the types of gray zones listed above, your client needs to know you’re doing it. It’s also good to tell your clients when you’re not billing them, because if you leave it ambiguous they’ll certainly be wondering.

Next Steps for the Honor Code

I think this code is really needed in the small-business WordPress website world, so I don’t want it to become just another thought experiment.

Here’s my plan for the Honor Code going forward, and how you can help:

Get feedback. Are the items on this list the right things for a WordPress developer to commit to? What’s missing from this list? I want to hear from you, whether you’re a client, WordPress implementer, WordPress developer, or anyone else. You can read, comment on, and suggest changes to the Honor Code at this GitHub repository. The comment section is also a great place to start, or you can email us (contact@) if you’d rather communicate privately. Finalize Honor Code. When I’ve gotten enough feedback to feel confident in the content of the Honor Code, I’ll publish a final version here on WPShout. Let developers publicly commit to Honor Code. I want to create a public site where WordPress developers and development learners can formally commit to the Honor Code. They’ll add their name and business name to a list of developers who have made the commitment, and they’ll get a seal that they can use on their sites, directing their clients to the details of the Honor Code itself. The National Society of Professional Engineers does a similar thing, if you’d like a reference. Allow client feedback on public site. The clients of listed developers should be able to use the public listing site to give specific feedback on how well the developers upheld the Honor Code. This doesn’t ask “was my project a success?” but rather “did the developer uphold his or her commitments as listed in the Honor Code itself?” Encourage clients to find developers through public site. Over time, I’d like the listing site to be a place where clients go to find developers who have formally committed to doing their jobs properly. Their ability to give feedback that other clients will see will create an accountability structure within the sub-community that simply doesn’t exist in WordPress as a whole.

So there are a number of steps here, but the first one is to get the Honor Code itself as good as possible. Please take some time in the comments section (or by emailing us at contact@ if you prefer privacy) to tell me:

What you think of the Honor Code as currently written, What should be added, removed or changed, and Any thoughts you’d like to share on the idea itself, and the project steps I’ve outlined above.

And as a final piece, if you want to sign the Honor Code once it’s been revised, let us know with an email to contact@ and we’ll keep you updated on progress.