In this article, I cover a number of patterns that crop up in my own WordPress client work, and in what I hear from others, both clients and other developers, about the shape and outcomes of their WordPress projects.

These patterns are, specifically, negative: consistent signs that either a developer or a client, or even an idea, may not be well-positioned to succeed as a WordPress client project.

This article’s structured into three parts:

1. Developer warning signs: signs that the developer lacks important knowledge
2. Client warning signs: potential signs of trouble behavior
3. Project warning signs: signs that a project idea itself may not be well-conceived

I really hope this is of general use to people—both WordPress developers and people looking for WordPress development help—as they look to make 2017 a year in which more WordPress projects are a success for all involved. (That could even be a good New Year’s Resolution for all of us, if you’re still looking for one!)

I also hope that this article, which is rather critical throughout because of its structure, doesn’t feel unduly so to people. None of these principles are hard-and-fast: successful WordPress projects have existed that have contained each one of these “warning signs”—though probably not all of them all together. These signs are, instead, consistent trends that I’ve seen both executing and witnessing a number of successful and unsuccessful WordPress projects over the years.

WordPress Developer Warning Signs: Signs of Incomplete Knowledge

If you’ve ever paid to have a website built, you probably have at least one painful story about a past developer. Unfortunately, “web developer” as an industry is highly populated with incompletely skilled practitioners, and web developers are also one of the most challenging professions for a non-technical consumer to intelligently compare and evaluate.

Before we look at warning signs themselves, let’s briefly summarize why the industry is the way it is. Here are some key reasons why WordPress developers’ knowledge varies so widely:

1. No licensing regime. Virtually all web developers I’ve ever met are self-taught. I can’t think of a person I know who got an undergraduate or graduate CS degree to do WordPress development, and relatively few developers I know are even products of the code schools and bootcamps that are becoming more popular. Most people learned how I did: by hacking on pet personal projects and favors for friends/families/internships until they thought they were good enough to charge. This leaves a pretty huge spectrum of potential skill levels—all going under the heading “web developer,” and all mostly indistinguishable to the consumer.
2. Huge and diverse body of needed knowledge. Ask yourself: “What does a WordPress developer need to know to do her job well?” Here’s a stream-of-consciousness list of knowledge I draw on for even simple client projects: HTML, CSS, PHP, principles of SEO, all key WordPress design principles and APIs, theme and plugin authoring, clean coding practices and WordPress standards, troubleshooting techniques, knowledge of best-in-class plugins for common needs, jQuery, Ajax, responsive design, site performance, object-oriented programming, basic principles of web security, dynamics of the hosting industry, basic server administration, rules of thumb for evaluating WordPress themes and plugins, basics of UI/UX design, basics of web business strategy, project estimation and management best practices, WordPress training and education. Take away any of these, and I’m significantly worse at my day-to-day job. And that’s not even counting the stuff (Git, WP-CLI, Composer, React, Node, Flexbox) that I should know better than I do. As a developer, you learn all of these on the job, and not in a terribly structured way—which means that it’s quite likely that you simply don’t know some of this stuff, hurting your clients as a result, with nobody knowing there’s a problem.
3. Highly technical job that’s opaque to consumers. Almost all consumers will be unable to tell, in a structured way, whether you are qualified to do your job. A consumer might judge by your portfolio—but she can only judge by how it looks, not by whether it’s rickety and difficult to manage on the backend, or whether tight coupling will make it impossible to change or extend, or whether it contains business-threatening SEO mistakes. So consumers, by default, have access to almost no reliable cues to distinguish highly qualified web and WordPress developers from less qualified ones.

With those facts discussed, below are some signs that a particular WordPress developer may be less qualified than would usually be helpful for a WordPress project to go well.

Developer Warning Sign 1: Doesn’t Know PHP

This is a very big and bright dividing line. Many people who build WordPress websites can’t actually read or write code—specifically PHP, WordPress’s most important coding language.

Building a WordPress site without PHP knowledge carries inevitable costs for the site’s technical quality.

If your developer doesn’t know PHP, it will be virtually impossible for her to build a WordPress site of any high degree of quality. The deficiency will be in the robustness of the site’s technical architecture, not necessarily its appearance to users; much of the rest of this section gets into the various detours that developers will take to cover for a lack of facility with code, and explains why all of these detours, given the present state of WordPress and the web generally, have serious and unavoidable side-effects.

The best way to find out if your developer knows PHP is to ask. Here are a few good questions:

• Do you know PHP?
• Can you point me to a bit of PHP code you’ve written recently, and explain to me, in general terms, what it does?
• Do you have anything up on GitHub that I could take a look at?

Having nothing on GitHub isn’t really a “warning sign,” but it’s very nice if your developer does have something up there. That means, at the least, that she understands the premise of Git, and is interested in sharing her ideas about code with herself and the world—in other words, she takes code seriously, which is a very good trait for your developer to have.

Developer Warning Sign 2: Doesn’t Know WordPress’s APIs

Knowing PHP does not automatically mean that your developer will know the WordPress APIs that make WordPress programming possible. However, she will be very well-equipped to learn, since those APIs are, in general, readily learnable by PHP-literate programmers.

To get at the general scope of your WordPress developer’s knowledge, you could ask some of the following questions:

• Do you have any plugins in the WordPress plugin repository?
• Have you ever written a private WordPress plugin on a past client project? Are you able to show me what it does?
• Have you ever coded a WordPress theme from scratch?
• Do you know how to register new widget areas without installing a plugin? (You can say you’re worried about plugin bloat, which is a reasonable position to take.)
• Do you know how to register new featured image sizes without installing a plugin?

In particular, a WordPress-literate developer should write private plugins quite often, as this is the way to make functionality changes in WordPress (unless they affect only presentational details like image sizes, which is best placed in the theme’s functions.php file).

As a cheerful plug on this topic: if you need to better understand WordPress’s APIs and technical systems, our multimedia package Up and Running is for precisely that purpose, and will be launching in a revised, updated, and expanded 2017 Edition in a few months.

Developer Warning Sign 3: Uses Mass-Market Technology Choices that Attempt to Route Around Technical Knowledge

This topic goes hand-in-hand with “Doesn’t Know PHP,” but could also crop up when a developer doesn’t know CSS, or knows PHP but doesn’t know WordPress’s APIs.

Many WordPress projects fail when the developer turns to mass-market technologies to route around gaps in knowledge.

Basically, many WordPress projects fail because the people tasked with WordPress development attempt to use mass-market technologies—most commonly “kitchen sink” themes and drag-and-drop page builders—to route around their own gaps in knowledge. Given a specific but reasonable definition of good, these technologies make it difficult or impossible to deliver a good WordPress website to the client.

As a WordPress developer, I believe any good WordPress website should have the following properties, among many others:

1. It should make good use of WordPress’s existing systems, and avoid arbitrarily substituting in private replacement systems.
2. It should, as much as possible, maintain the elegance of WordPress’s separation of concerns: plugins or themes should leave the rest of the site intact when deactivated or switched, and multiple elements of the site’s architecture should not be coupled together into one inseparable mass.
3. It should be performant, meaning as lightweight and quick to load as is feasible; it should not rely on architecture decisions that place an undue strain on site performance.

Having offered this definition of good, I can now assert that, unfortunately, some very common ways of building WordPress sites simply do not lead to good results. I will name three: Divi (“all-in-one” theme), X (“all-in-one” theme), and Visual Composer (premium page builder plugin).

These three products are giants in the general WordPress space, and they’re the largest and most obvious examples of a more general trend. (I don’t like writing negatively about specific products, but I’m comforted by the fact that each has made its creators untold millions, and this article will do nothing to change that.) I’ve worked with all three on multiple client sites—more than enough to know how unsatisfying they are with respect to the criteria I listed above.

The trend that binds these products together is that they try to let you do WordPress development without coding knowledge. In other words, they take abilities that are generally in a WordPress developer’s purview, and try to give those same abilities directly to consumers.

This is a wonderful goal, and it’s where the web is heading and should head, despite the more and more total disruption this will continue to entail for web professionals who develop small sites using WordPress and similar tools. We’re slowly going the route of professional typists—a once-broad category of middlemen turning increasingly niche—and that’s as it should be because of the benefit to consumers.

The technology still does not yet exist to develop a well-functioning WordPress site without a professional developer.

So the issue isn’t philosophical, it’s practical: in the technological environment that exists today, trying to develop a complete WordPress site without the aid of a professional developer who knows how to code leads to bad results. “Bad” here has both its commonsense meaning (sites are often slow, ugly, and broken), and also indicates the opposite of the narrow three-part definition of “good” I gave above.

As I look at these three leading “develop without a developer” technologies in WordPress, try to keep in mind the common thread: how, given presently available tools, attempting WordPress development without access to a technically informed person entails tradeoffs that ultimately lead to a bad final product.

“Everything Themes” such as X and Divi

Here’s the X theme describing its theme editing options:

“Finally, imagine that you were also provided with unprecedented controls that allowed you, with the simple click of the mouse, to make an endless amount of adjustments to your site. Want the header fixed and huge on the left? No problem. Want it floating and skinny at the top? You bet. Want the max width of your site to be only 500 pixels? You got it. How about a cool textured background or image? Absolutely!”

The Divi theme tells essentially the same story in describing its header options:

“Divi comes with a plethora of header options that allow you build really unique looking websites. Choose between a left aligned or centered logo. Switch between vertical and horizontal navigation. Adjust colors, enable transparent headers or opt to hide your navigation before scrolling. There are even full screen and slide-in navigation styles that work great on mobile!”

Developers will recognize these user options as precisely the developer decisions that one makes in building a WordPress theme. Because these fundamental layout elements should almost never change on a site, they’re best locked down in static CSS stylesheets and PHP templates. If one day the site owner decides that she wants a left nav menu instead of a top one, that means that the theme’s files should now change to reflect the new layout.

However, X and Divi must give the user the option to change any of these elements at any time—with no technical language. That inevitably means a lot of complexity baked right into the theme itself. At every step in its process of building itself, the theme must constantly ask questions like “Does the nav menu go here?” or “Is the site boxed or full-width?” or “Which of our four Stacks is the site owner using?” Rather than being a set of presentation decisions, the theme is a giant machinery of interlocking questions.

Where do the answers to these questions live? Since the whole premise is that the site owner doesn’t need to know any technical language, they’re not going to be anywhere in the theme’s filesystem. Instead, they’re stored, as theme options, in the WordPress database. This forces the theme to query the WordPress database to understand the current value of each of its layout elements—even classically static properties like an element’s maximum width or the presence or absence of a sidebar. Sending dozens of database queries on every page load just to understand how your own site is laid out is about the slowest thing you can do, so this architecture inevitably suffers a major hit in performance. Whether these performance issues are noticeable to site users depends on numerous things, such the quality of the hosting and the caching solutions in place—but the underlying architecture is, unavoidably, both significantly slower and much more difficult to work with relative to a cleanly coded WordPress theme with actual decisions in its theme files.

There’s also the consideration that most nontechnical people generally want the theme they purchase to have all the features they could possibly want, despite themes’ proper role as a controller of presentation rather than underlying data. As a result, many commercial themes suffer mightily from theme creep, the market-driven tendency to “do it all” within your theme. Elements like custom post types, custom taxonomies, general site data (such as social media and Google Analytics links), and even A/B testing suites often get bound up in the theme itself, so that the theme touches every aspect of what the site can do, rather than merely controlling its visual presentation. The result is a “tightly coupled” site where everything is glued together, which unfortunately makes bugfixes, changes, extensions, and redesigns unduly complicated and painful.

None of this says that either X or Divi is badly built for what it is, which is an “everything theme”: a theme that tries to offer every possible thing to everybody, with no needed technical knowledge. Divi promises this directly in a called-out review on its homepage:

“If you don’t know how to code your own WordPress theme, but you want a beautiful custom website, Divi may be just the theme you’re looking for.”

Rather, the point is that creating an “everything theme” inevitably implies both worse performance and a confusing quantum fog of hundreds of options in your theme files—and, in practice, generally implies a wealth of theme-creepy bundled features.

And, again, there’s nothing unique about X or Divi in this regard except that they’re exceptionally well-marketed. Probably most themes available on ThemeForest have far too many options and features and are slow and hard to work with as a result. Here I feel obliged to drop in the Avada theme‘s tagline, despite a personal soft spot for Avada (I used it to build my mom a site a few years ago).

So the point isn’t that any one theme or theme vendor is nefarious. The point is that, despite the strong pull of market demand for such a solution, there is currently no theme-based substitute for an actual, professional, code-savvy WordPress developer which does not entail major sacrifices in the quality of the resulting site.

Page Builders: Visual Composer

One thing separating the X theme from Divi is that Divi ships with its own page builder, the Divi Builder, whereas X ships with the Visual Composer page builder plugin. Both work about equally well, which is to say that they attempt a worthy goal, but they create a big mess in the process and make a developer’s life much harder.

Visual Composer comes bundled with hundreds of commercial themes. Why is it so popular? Here is its landing page tagline (right below “1,500,000+ People Can Not Be Wrong…”—which I can’t help pointing out as an extremely poor assessment of whether imperfect things ever achieve mass popularity):

“Visual Composer page builder plugin for WordPress – take full control over your site. Build any layout you can imagine with intuitive drag and drop builder – no programming knowledge required.”

In other words, Visual Composer exists to take web developers out of the process of building page layouts. Again, this is a wonderful goal: I’m consistently embarrassed when my clients ask me “How do I put this part into two columns?” and I have to tell them “Let me do it.” In fact, I’ve started using a much cleaner and more lightweight page builder, Tailor, for some of these light layout tasks—although it’s a small and new project and is still pretty buggy. Case in point: I originally wrote this post using Tailor, and at a certain point it crashed its Chrome tab with a memory error. It doesn’t have the WordPress post editor’s autosave features, so I lost a day’s work (about 1,000 words), which is why the observant among our readers will spot that this post is a day late.

So the issue isn’t the goal, it’s that the current solutions make massive sacrifices trying to reach it. Visual Composer in particular is, unfortunately, a hallmark of bad WordPress development. Pippin Williamson’s comprehensive review of WordPress page builders gives the two main reasons why:

1. “Visual Composer has a really, really strong lock-in effect due to its use of shortcodes for layout construction.”
2. “Common compatibility issues… related to shortcodes.”

In other words, because Visual Composer handles everything with shortcodes in your page content, it’ll break a lot of other pieces of software. Also, if you ever try to uninstall it after using it, it’ll break your site.

Why Aren’t Page Builders Perfect Yet? Complexity in HTML Layouts

Visual Composer’s use of shortcodes was a poor architecture decision that is now locked in, but no page builder does exactly the simple thing that everybody wants: let you edit your website’s pages as simply and intuitively as a Word document, without unexpected behavior. The fundamental reason is that there is a great deal of irreducible complexity in HTML layouts themselves.

Let’s take one example: trying to create a paragraph with an image next to it, each taking up half of their containing element. Let’s say the containing element is 800px wide. If I, the page builder user, set the image to be “400px wide,” do I mean always 400px, or do I mean “always half as wide as the containing element”? If I really do mean “50% the width of the containing element,” then am I including or excluding the containing element’s margins? What about the containing element’s borders and padding? What about the borders, padding, and margins of the image itself? What about the padding and margins of the paragraph? If I view the whole thing on a phone, causing the containing element to shrink to 360px in width, do I really want a 180px-wide paragraph (that’s disregarding everything’s margins and padding, of course), or do I want the image to break above the paragraph so that both are now full-width? If that’s what I want, what’s the minimum width at which both the image and the paragraph should stop being 50% wide and become 100% wide?

Translating intuitive page builder commands into detailed CSS rules that cover all possible device widths is an irreducibly complex problem.

If you want to actually specify these distinctions, there will never be anything simpler than CSS, which is the language of these distinctions. But knowing CSS is precisely what page builders try to shield us from. Translating a page builder user’s vague mouse clicks and slider drags into sensible CSS rules that cover all possible device widths is an irreducibly complex problem, and so all page builders suffer some combination of restricting the user’s freedom (with predefined elements and limited option sets) and allowing unexpected behavior (“Why does the site look like this on my iPad?”).

One trend in CSS is layout modules such as Flexbox, whose behavior changes much more intuitively and fluidly at different widths and sizes. As these evolutions of CSS continue to gain traction and full browser adoption, page builders will become better and better.

At present, though, you unfortunately still need a WordPress developer to oversee the creation of high-quality novel page layouts, like a multipart homepage or an About page with slide-out team bios. For simpler content like blog posts, you’re best confining yourself to single-column text flows with images and other media. Anything else, in practice, will want a developer overseeing it. (Even this post “cheats” with special CSS classes for our blockquotes.)

Practicing WordPress development with tools whose marketing mentions things like “you don’t know how to code your own WordPress theme” simply does not put your clients in a good position.

All this brings us back to WordPress developers themselves. People who build sites in WordPress on top of technologies whose marketing mentions things like “you don’t know how to code your own WordPress theme” and “no programming knowledge required” are simply not putting their clients in a good position. The issue is simply a lack of familiarity with the programming principles that make WordPress development actually work.

If you see your developer implementing X, Divi, any other top-selling “do everything” theme, or Visual Composer on your project, be cautious. You may be happy with the site that results from using these technologies, but it will be fragile and hard to work with in other ways, and the lack of experience your developer is signalling is likely to indicate inexperience with other very important topics in web development.

Developer Warning Sign 4: Less than Two Years of Experience

When I started doing WordPress development, I made huge mistakes all the time, simply because of the vast body of practical knowledge I had not yet acquired. This meant everything from trying to code a theme from scratch in the style of an HTML website (the client wisely backed out after I stayed up all night), to badly damaging a site’s search traffic by failing to redirect its URLs after a redesign, to badly damaging another site’s search traffic by leaving “Discourage Search Engines” checked after launch.

None of this had anything to do with my knowledge of HTML, CSS, PHP, JavaScript, or even of WordPress’s APIs themselves. Rather, these were practical mistakes, failures in know-how because of inexperience.

On the other side of the coin, with every month that goes by I get better and better at my job: improving and streamlining my own development workflows, finding workarounds to what could be very difficult problems, refining my list of the right solutions for dozens of common problems and feature needs, learning to avoid pitfalls and gotchas, finding wonderful but obscure plugins and tools, improving the clarity of my communication with clients, and so on.

Becoming a good WordPress developer takes more than programming knowledge: it takes, inescapably, time.

The point is that becoming a good WordPress developer, in the complete sense of “able to shepherd a WordPress project from idea to successful result” takes more than programming knowledge. It takes, inescapably, time. I would not recommend you hire me three years ago, and I would not recommend you hire any agency whose senior developer attached to your project has fewer than two years of experience working, more or less full-time, as a WordPress developer.

I’m aware of the Catch-22 here, and I don’t propose this as a hard-and-fast rule. If your developer is relatively new to the job, she will simply have less practice doing it, and you should factor that in.

Developer Warning Sign 5: Low Hourly Rate

Virtually all new developers charge too little per hour.

Virtually all new developers charge too little per hour. I started at $30 per hour, reasoning at the time that $30 times the number of work hours in a month equated to a reasonable starting salary.

What slowly dawns on you is overhead: all the work you must do that you cannot bill for. Email, blogging, newsletter mailings, social media, advertising, maintaining your agency site, networking events, initial consultations, proposals and estimates, invoicing, accounting, taxes, meetings, professional development, travel: as a freelance WordPress developer you’re extremely lucky if most of your time isn’t taken up with activities that you do entirely for free.

As a result, the commonsense starting rates that beginner developers assign themselves are completely incapable of making them a living. Experienced developers have learned this lesson, and they charge accordingly. $100 per hour (which is what I charge) is a reasonable rate for a good developer. $250 per hour is generally at the high end: a confident, experienced developer with a clear method of finding clients who value her work. $60 per hour feels, to me, like the minimum hourly rate that could make sense for a developer (even a beginner) who lives in a country with a high cost of living. $50 per hour or lower is cause for serious concern, because the developer has not yet learned to value herself in the marketplace, and is likely inexperienced in many other aspects of the job as well.

As a note, even if your developer flat-bids your project (“It’ll cost $2,000”), she will still know the hourly rate she used to generate that flat bid. Feel free to ask what that number is.

Developer Warning Sign 6: Found through Freelance Exchanges

A very attractive way to hire creative and technical talent is through large freelancing websites like oDesk, Upwork, Elance (all three of which appear to be merging), and Fiverr. However, you need to be very careful with WordPress developers you find through these sites.

The primary reason is economics. These sites expose developers to the most nakedly capitalistic commodity-market forces of any method of finding work, and put developers from countries with a high cost of living in direct competition with developers from countries with a much lower cost of living.

Because these sites are such a difficult way to find work for developers from wealthy countries, those developers are likely either to be relatively inexperienced (see “Low Hourly Rate”), experiencing difficulties finding clients by other means, or pursuing some kind of extremely-high-volume strategy that will likely curtail your freedom to give input and request revisions.

You may have excellent results saving money by hiring developers from countries with a lower cost of living. Just do your due diligence, as coding practices, standards of quality, and expectations around communication can interact both with individuals’ approach to work and with geographic differences.

Developer Warning Sign 7: Small Organization, with “Development” Given Secondary Billing

Web work carries lots of different job descriptions, many of which—like SEO, graphic design, and digital marketing consulting—often heavily involve a website as a central online asset. As a result, there are lots of people who are not primarily developers, but who have a lot of experience working with and tweaking websites, since a website is often needed before their work can begin in earnest.

The danger to you as a client is if you engage a professional whose primary focus is not web development, and agree to have her build or heavily modify a WordPress site for you as part of that engagement. This isn’t really a concern for larger agencies—”larger,” here, meaning three or more full-time employees, because agencies this size and up will usually have at least one well-qualified technical person who focuses specifically on clients’ tech needs.

But one- and two-person agencies simply can’t focus on everything. Hiring a professional social media marketer to develop your WordPress website is just as dodgy and tenuous as hiring a professional WordPress developer to manage and grow your social media presence: in each case, the person you’re hiring may know both topic areas, but there are no guarantees, especially considering the depth of knowledge that true expertise in either field requires.

Professionals in other fields who also build WordPress sites often make bad WordPress technology choices.

In practice, the danger here boils down to “Doesn’t Know PHP” and “Uses Mass-Market Technology Choices that Attempt to Route Around Technical Knowledge,” as a lack of PHP knowledge pretty much always implies heavy engagement with the tools that are supposed to help you bypass this knowledge. It’s simply that professionals in other fields who also build WordPress sites are a very common source of bad WordPress technology choices. If your contractor isn’t going to try to slap the X theme and Visual Composer together and fiddle with settings until you have a site, you should be fine—but at that point, she’s a WordPress developer!

WordPress Client Warning Signs: Worrisome Behavior Patterns

Some types of clients seem, in a predictable way, to make WordPress projects difficult. (I’ve written more about this elsewhere, if you’re interested in a differently organized take on similar material.) In my experience, the two broad, primary client traits that can really spell trouble for a WordPress project are:

1. General confusion. This means confusion beyond simply not knowing the best technology choices to make—which is where a developer should come in—and could include unrealistic expectations, a serious lack of strategic clarity, or even a lack of general competence (such as not being able to schedule meetings or follow through on tasks).
2. Unwillingness to pay. Some clients are simply deceptive or manipulative in the way they approach developers—most often and most especially around money.

The section below looks at specific behaviors and traits that, in my experience, often act as warning signs for these two general problems.

Client Warning Sign 1: Generally Confused

In my experience, just about nobody fully knows what they’re doing online. In that, I strongly include myself, as well as giant companies like Twitter and Groupon that keep discovering how hard it is to become and stay profitable online.

The question is how much confusion you’re able to tolerate and help the client work through, and at what point confusion about technology choices bleeds into generalized confusion about strategy, what to realistically expect from a WordPress project, the fundamentals of succeeding on the internet itself, and even basic work practices like keeping appointments and following through on obligations.

Below are some warning signs that a client may be thinking unclearly or unrealistically in ways that tend to endanger the overall health of a potential WordPress project.

Disorganized or inconsistent.

Your client’s behavior early on in the relationship is an important indicator of how your project with her will proceed. Be highly alert to last-minute meeting cancellations, missed deadlines, dropped email threads, rambling or one-sided conversations, and other lapses in general competence and efficiency: if these types of issues are cropping up at the very beginning of the relationship, it’s usually the tip of the iceberg in terms of how the project itself would proceed. Your client will be judging you along these dimensions as the two of you establish trust, and you should do the same.

Furious at (and/or just fired) a previous developer.

It’s sad but true that almost anyone on the web has had a bad experience with a developer. This is the fault of developers, not of clients. Nevertheless, all things being equal, it is a worrisome sign if your client is still seething over a relationship with a previous developer, particularly one she’s just fired.

It’s possible that the developer was simply incompetent or dishonest or both, and that this eventually became intolerable. In general, though, all stories have two sides. Given that the developer’s work was not even close to what the client was looking for, precisely how did communication break down to let this situation develop into a crisis? Were expectations communicated ineffectively, or simply left locked up in the client’s mind until too late? If the developer left important things unfinished, could this be because the client was unwilling to pay invoices (which she feels she shouldn’t have to pay because of complaints with the work)? Is it possible that the client changed the site’s basic strategy three times during development, and was unprepared for this to massively extend the project’s timeline and budget? Again, it’s possible that the problem is a bad developer, full-stop—but since you’re hearing only the client’s version of events, if the story does have these extra dimensions, you likely wouldn’t hear about them.

The past is one of the best predictors of the future. You should try to intuit as much as you can about what happened with the previous developer, and move forward only if you’re reasonably sure that you have the power to prevent the pattern from repeating, with you as the next bad ex-developer.

Demands features rather than solutions.

Sometimes, a client will contact you not with a discussion of her needs and underlying goals for her site, but with a very specific and strange-seeming feature request—something like “Can you do header shortcodes?”

In general, this is the result of the client Googling around for solutions to her underlying problem, concluding that some combination of the results of those searches is what she needs, and contacting you to ask if you can build the result. I’ve noticed doctors being similarly thrown off when I show up with my own diagnoses. In both cases, the issue is a general lack of knowledge, combined with a (in some ways admirable) do-it-yourself attitude.

If you let your clients treat you like a short-order cook, you won’t like your job, and they won’t like their websites, so you want to break this pattern early.

In these situations, it’s quite important to reorient your client toward identifying the underlying problem or goal that’s motivating what she thinks is the feature need. This might initially be something like “I want my header to have a search form”; better yet is, “My site visitors can’t find my old articles,” which is finally at the level of needs rather than features. Digging to the underlying goal will help guide the client toward the right solutions to her actual needs, and, crucially, will train the client to relate to you as a source of valuable insight into her technology choices rather than as a mute builder of requested features. If you let your clients treat you like a short-order cook, you won’t like your job, and they won’t like their websites, so you want to break this pattern early.

You should start to be quite concerned if the conversation bogs down, with the client simply dogmatically demanding the original weird feature. In some cases, the issue is simply a lack of trust in a new relationship: telling the client “there’s probably a better way to solve your underlying need, if you tell me what that is” can sound like a sneaky way of saying “I don’t know how to do what you’re asking for.” In that case, you may just want to build the feature (if it’s quick and you’re being paid) to make it clear that you do know your job, and then work to reorient the client toward articulating her underlying needs, and to viewing you as a technology advisor rather than a mute builder.

But a client who dogmatically demands features may simply be unable to see you as anything but a mindless fulfiller of directives, may be incapable of clear communication (at least with you), or may not know what she wants—or all three. In my experience, clients with these traits also tend to be very unattractive in most other respects (relentless haggling on price, manipulation and deception, permanently unclear strategic direction), so be prepared to jump ship if you can’t get the communication flowing.

Multiple competing stakeholders.

This is a special case that happens in projects with larger clients. It relates not to individual confusion, but to the collective confusion that occurs when multiple conflicting voices within an organization push and pull a project in multiple directions.

In the early stages of a relationship with a larger organization, you should understand clearly what personal relationships you will have within that organization. Who can tell you to make changes? Whose say is final? Do you have one specific liaison overseeing the project, or will you be communicating with multiple people throughout?

Try to advocate, as much as possible, for a relationship with a single stakeholder who is your only direct liaison.

In some cases—perhaps especially with less streamlined and capitalistic organizations such as local nonprofits—you may find that these questions don’t have clear answers. In this case, try to advocate, as much as possible, for a relationship with a single project manager, who takes input from other stakeholders but has final say on the project, and who is your main or (ideally) only source of direct communication. Emphasize that unclear or inconsistent directives result, above all, in projects that run long and go over-budget.

Client Warning Sign 2: Barriers to Payment

Some people wish to manipulate developers into working for free—either from a lack of scruples, or a perceived need for development help combined with an unspoken inability to pay. This is especially true for smaller projects that a WordPress freelancer is likely to pick up.

Wishes to pay you in something other than money.

“Exposure,” “referrals,” and “future business” are nice things to have, but they are not a substitute for being paid your full rate as soon as you begin to render professional services. Be wary of clients who seem to be starting to suggest a bait-and-switch of this nature.

Keeps emphasizing the size of the market as a sign of opportunity.

Knowing the size of the market you’re in is a sign of good business, but some potential clients will present a large market (either in statistics or simple statements of hugeness) as a surefire sign of opportunity: “Of course we’ll all get rich!”

The question isn’t whether there’s money flying about—of course there is. The question is whether you are positioned to compete in the crowded marketplace that inevitably forms around anything of value. “Cars” is a $1 trillion industry or thereabouts, but you can realize precisely 0% of that industry without things like working capital, inventory, and a trained sales team.

Simply throwing around market numbers to bludgeon a developer into excitement is a sign of inexperience, as well as a potentially troubling tendency toward substance-free dazzle.

Requires NDAs for non-novel or purely speculative ideas.

In my work as a relatively small-scale WordPress freelancer, I’ve never found an NDA I thought was necessary. If you’re being asked to build a website for an extremely early-stage venture that hopes to eventually develop something nonspecific like “better marketing analytics,” and the client requires an NDA, it can be a bad sign—pointing either to inexperience (experienced entrepreneurs have learned, painfully, the world’s general indifference to new ideas with nothing visible to back them up), or to a generally litigious and suspicious mindset that may bog down the project in other ways, such as around payment.

Wants you to work for equity.

This is a specific subset of “wishes you to work for something other than money”: the client wishes you to work for an ownership stake in the business itself. I’ve been asked to do this a number of times, and I’ve never seen a situation where it was anything but crazy. Let’s ask a few questions about this idea.

If your business really is poised to take off, why would you want to share legal and financial ownership of that business with your WordPress developer?

First, if you really have a business idea that is poised to take off, why on earth would you want to share legal and financial ownership of that business with your WordPress website developer? Without insulting WordPress, that’s a bit like paying rent to your plumber.

Second, how will this “ownership” actually work? Is the business properly incorporated and is there a shareholder agreement, or will the client need to spend a few thousand dollars putting these sorts of legal arrangements in place? Will there be quarterly dividends? As part owner, do you have a say in the affairs of the business? Is this conversation at all sensible in the context of a $3,000, $10,000, or $20,000 WordPress website?

Third, taking an equity stake in a business is a statement of confidence in that business. What are the good reasons to be confident in the specific business being discussed, given that it must resort to exotic financing structures to fund the completion of a WordPress website?

Unless your income on the project will be in the hundreds of thousands of dollars or more and, for example, the founders wish to pay you partly in equity to avoid having to raise venture capital money, proposing that you work for equity is simply code for a client who doesn’t want to pay you.

Attempts to defer initial payment.

Discovering a client’s needs takes time, as does creating and finalizing a proposal. However, if and when it’s clear what you intend to do and that you are the person who will do it, payment should be forthcoming.

For many clients, paying a developer the first block of 10 or 50 hours is a moment of truth. As a result, unscrupulous clients will keep trying to get a bit more out of you until they’re “sure.”

This is a very bad sign for the overall prospects of the project, so emphasize that you don’t work for free. Be prepared to cut your losses if payment remains an issue.

WordPress Project Warning Signs: “Network Effects” Business Models

Some websites are like stores. If I visit a furniture store, my main concerns are the quality of the goods on display, and whether they fit in my budget. If there are other people in the store, that may be helpful (perhaps they leave helpful reviews)—but, overall, it’s not necessary that other people be using the store at the same time for me to have a good experience there.

Other websites are like parties. A party only works if there are lots of people there at the same time. Also, parties only make money (if they do make money) by charging a little bit to all the people who come to see what all the fun’s about.

Some website ideas entail network effects: they’re only valuable if they’re large and widely used.

The fact that a party’s quality varies directly with its membership is called a network effect. Many websites work the same way: they’re only valuable if they’re large and widely used.

Throwing a party is scary business. What if no one shows up? What if everyone thinks that no one will show up? (Then no one will show up!) Starting a party online is even more difficult, and I’ve learned over a fair amount of experience that most network effects-heavy ideas that involve WordPress are unlikely to succeed.

Marketplaces

A marketplace is any platform that connects buyers and sellers (or providers and users) of something.

Online marketplaces are some of the internet’s most lucrative businesses. Here are a few: Amazon, Uber, Airbnb, Craigslist, eBay, Groupon.

These businesses all share a common feature: they were in the right place at the right time to grab the lion’s share of a huge market. That’s their competitive advantage: everybody is already using them.

None of them is terribly complicated technically. You could build a Craigslist clone in WordPress in maybe a hundred hours. But nobody would use it, for two reasons:

1. There are too few goods listed, so buyers won’t use it.
2. There are too few buyers perusing the goods listed, so sellers won’t use it.

So a marketplace business must solve two problems at the same time: creating a good buyer experience (which means hosting the right inventory, typically meaning lots of sellers listing themselves) and creating a good seller experience (which means lots of buyers browsing and making purchases).

Now, back to WordPress: If you’ve got a great idea for a marketplace business, why are you using WordPress?

WordPress is not the right choice, in the long term, for a very large marketplace site.

WordPress is not the right choice, in the long term, for a very large marketplace site, because it has a set way it organizes data, built around the concept of posts. To rework Amazon or Airbnb or Craigslist to run on WordPress would be a terrible idea—whereas doing so for Time.com made perfect sense.

Instead, the traits that attract many would-be marketplace site owners to WordPress include:

• It’s easy to use
• It’s free
• WordPress developers’ project estimates usually run in the thousands of dollars, not tens or hundreds of thousands

In other words, WordPress as a tool for marketplace sites is most likely to attract people for whom better long-term technology choices would simply cost way too much.

To found a successful marketplace business,you need to be able to execute a plan that will bring both buyers and sellers online at the same time in large numbers. To do this, it’s really helpful if you have deep pockets, so that you can launch with a concentrated marketing and advertising blitz targeting both your buyer and seller communities. Most potential marketplace site owners who turn to WordPress won’t have that luxury, so we’ll have to hope that they have an unusually profound degree of strategic clarity and marketing know-how.

Unfortunately, lacking access to the capital needed to get something built on appropriate technology is often (although of course not always) accompanied by a more general lack of strategic clarity. Just to make this point practical, here are the most recent marketplace site ideas I’ve been approached with—in precisely the level of detail that the potential clients presented:

• A place to buy and sell wine.
• A place for teachers to connect to students, either online or in-person.
• A Bitcoin and currency trading site.
• A place for churches in America to find and hire ministers and church musicians.

All of these ideas were extremely vague, and none of them came with much of the strategic awareness that would give them a reasonable chance of succeeding. What competitors exist, and why are you an improvement? How will you find and grow a core user base? Why are you trying to launch nationally or globally, and do you have any reason to believe that network effects won’t doom that type of widespread launch?

Honestly, none of these project ideas even had a clear revenue model—that is, how they’d make the site owners money even with lots of users. That was presumably a problem that would solve itself once the service got huge. And every one of these project ideas was accompanied by relentless downward pressure on price.

In general, people interested in starting a marketplace site who turn to WordPress have neither the money and marketing acumen to build those sites to a useful size, nor the strategic clarity to understand the difficulty of the challenge facing them. The main exception I can imagine would be someone looking to cheaply and quickly test an idea in a very local market, as validation for a larger and more expensive project on different technology; but I personally don’t often run into clients who are thinking in these terms. Marketplace sites as an idea tend to make me wary.

Social Networks

Many people who start a social network on WordPress lack a clear plan to keep the network from dying from its own small size.

Most of the main points of the marketplace site analysis above hold for social networks as well. Social networks in the vein of Twitter, Facebook, Instagram, and so on are not best built on WordPress, so people who choose WordPress as the technology typically do so out of inability to pay for more expensive alternatives. This generally also corresponds to a lack of appreciation for network effects themselves, and a lack of a clear plan to keep the social network from dying out as a function of its own small size.

The only two additional points I’ll make are, first, that people don’t come to social networks to make purchases, like they do at marketplaces. Rather, social networks generally have a single primary class of user, who are there to interact with others on the network itself around some shared interest or mode of communication.

This makes social networks harder to start than marketplaces, because the value proposition is fuzzier. “Facebook for Jazz Enthusiasts” wouldn’t be an unusual idea for a client to present, and the question becomes: What do people do on there? It’s very hard to find an answer that hasn’t been tried, either with success (share music files? See Soundcloud) or, much more commonly, with failure (just, vaguely, interact? See a million no-longer-functional social networks).

Even if “a social network for jazz enthusiasts” did have a strong and specific value proposition, Facebook itself would swallow the idea whole, since everyone’s already on Facebook and it has ways for people to organize around common interests—unless the idea is built around very novel technology, as, for example, Soundcloud is. If so, WordPress is extremely unlikely to be the right choice, since that technology and the social activity around it will do much better on a web architecture that is purpose-built. Even for a Facebook clone—if there was some way to make it strategically defensible, such as locating it in a country that can’t access Facebook—the right long-term technical answer wouldn’t be WordPress.

The second point I wish to make is that this doesn’t at all take away from the value of private “social networks” organized around common tasks, like crowdsourcing the pictures of a wedding or collaborating on a project. These aren’t social networks in the sense that they require vast open participation to succeed, and WordPress solutions (for example, BuddyPress and bbPress) can service some of these kinds of needs quite well. I will say, however, that tailor-made third party solutions (Slack for chat, Basecamp for collaboration, Trello for task management, and so on) are often better for most use cases than WordPress’s approaches to similar needs.

Let’s Toast to No More Bad WordPress Projects!

Whew! This feels like the longest thing I’ve ever written—and rather critical throughout, given the subject matter. I hope this article comes across in the spirit it’s intended, which is to help both developers and clients make better decisions. Please let me hear any thoughts in the comments below!

Image credit: Chris Phutully