Software, Development, and WordPress

For The Aspiring Professional WordPress Developer

When it comes to discussing WordPress development, I think that one topic that’s hard to come by is how to begin taking on professional WordPress development gigs.

Specifically, I think that we could do a better job of communicating what to expect when another developer opts to make the move to become a professional WordPress developer. And by that, I mean doing something part-time or full-time for pay.

For roughly the past two years, I’ve divided my time between self-employment and two startups the latter two using WordPress as the backbone for their software. For the former, I’ve built a number of plugins – most free, a few premium – and have worked on a number of contracts building sites, plugins, and applications for others.

With that said, I thought I’d do my part in sharing some advice for the aspiring WordPress developer.

Professional WordPress Developer Defined

Brogrammers can be professionals, too. Right?

Brogrammers can be professionals, too. Right?

I think it’s too easy to get caught up in the semantics of what constitutes a professional in any field.

So before talking about anything else, I want to level set how I’m defining a professional WordPress developer so that there’s some context for the rest of this article.

A professional WordPress developer is a programmer who makes a living (or contributes to making a living) by using WordPress to build products.

Easy enough, right?

Of course, this isn’t to discount what’s assumed about a professional WordPress developer. Clients will assume one, two, or all of the following things about you:

  • You’re fluent with PHP, JavasScript, HTML, and CSS.
  • You’ve built themes.
  • You’ve built plugins.
  • You’ve built applications.
  • If a problem is presented to you, you can likely solve it with WordPress.
  • You’re intimately familiar with the WordPress database schema.
  • You’re familiar with the various WordPress APIs.
  • There’s nothing you can’t do with WordPress.
  • You follow the WordPress best practices.
  • You write quality code.
  • You genuinely care about engineering a product over “just getting in working.”
  • …and many more.

Sure, some of these may sound outlandish to you, but they aren’t unreasonable.

So what’s a developer to do? Easy: Always be honest with what you know and what you don’t. If you’re not the right developer for a job, don’t waste your time or your potential client’s time trying to pretend that you are.

All moral issues aside, attempting to take on a problem that you’re ill-equipped to solve is more of an exercise in frustration than it is in productivity. I’m not saying it’s unacceptable to “cut your teeth” on new technologies on a given project, but that’s often better suited for a personal project from which you can bring back those learnings into a paid gig.

Anyway, here are the the things that I’ve found to be non-negotiable when it comes to managing and building successful projects.

Project Management

"What would you say you do here?"

“What would you say you do here?”

In the corporate world, there is normally someone who sits between the developers and the stakeholders (read: business people), but when you’re working for yourself that’s not the case. Instead, you are tasked with talking with the client about their needs in a way that they can understand.

The bottom line is this: If you’re talking to them the way to talk with your fellow developers, you’re probably doing it wrong.

To that end, we’ve got to make their experience with us as painless as possible. This is not as easy as it sounds, but it’s exactly where project management comes into play.

Project management includes everything from interacting with the client, gathering requirements, keeping in close communication, being responsible for your work, and getting changes in front of them as quickly as possible.

Requirements and Scoping


Scope That Project

One of the most challenging aspects of managing a project is balancing the requirements and the scope.

You often hear it said that “the client doesn’t know what they really want,” and I think there’s some truth to that (though it makes the client sound dumb, doesn’t it?).

Specifically, they have a vision for what they want, but when they see what they’ve described actually implemented, it’s often off-base from what they’ve pictured.

This is where scoping comes in: Identifying the MVP of every single project is key regardless of how large or how small the given project is. Developers are often good at thinking in terms of organizing information or data, and organizing a project is no different.

First, identify the MVP: Out of all of the given requirements, what lays the strongest foundation on which to build the rest of the project?

Use this as a baseline for scoping and it’ll help make developing on the project much easier, and it will help give the client an organized look at how the project will be executed.


You've got to keep your clients in the loop.

You’ve got to keep your clients in the loop.

I think one of the number one things developers are notorious for is their lack of communication skills. It’s believed that we’d rather take our introverted-selves, sit at a computer, and ignore whatever is going on around us.

I also believe that working in the corporate world makes this a bit easier as we’re surrounded by other developers with someone sitting between us and the stakeholders, but if you’re looking to make the move to a form of self-employment as a professional WordPress developer, then you can’t afford to do this.

You’ve got to remain in constant contact with your clients. This varies from project to project:

  • Some are comfortable using a system like GitHub pages or Basecamp.
  • Some may want weekly (or daily!) phone calls.
  • Some my want to review work as it’s being completed.

Regardless of the frequency at which your customers want to stay in touch, create milestones after which you can deploy to a staging environment, and then touch base with them to review.

Build in those feedback loops because few things are worse than building the entire project only to have a huge list of things to rework.

Milestones and communication mitigate that.

Source Control

"Use The Source, Luke!" Terrible pun.

“Use The Source, Luke!” Terrible pun.

This should go without saying, but every project that you manage should be kept under source control. With the popularity of GitHub on the rise, there’s no excuse why you shouldn’t have some form of source control.

But it’s more than just that: Sites like this allow you you to create milestones (based on requirements) for each project, allow you to track issues that the user reports, and allow you to create pages of documentation and/or notes from the various calls or emails that you have with the client.

Furthermore, you can use tagging to snapshot the code at various points in development – ideally at milestones, but that’s up to you – in order to deploy work to a staging environment and get it in front of the client sooner rather than later.

Again, all of it comes back to feedback loops.

Frequent Releases

Release your work frequently!

Release your work frequently!

One of the things that has made my life significantly easier as a developer is to have frequent releases. That is, I try to make sure that I am able to deliver something every single week to a client.

Sure, some weeks are going to have more features than others, but showing continuous movement (read: development) on a project is good for the client, and it helps to gather feedback to make sure that you’re capturing exactly what it is that want as per the requirements.

If so, then you’re good to go. If not, then you’re free to update the following milestone or introduce a bug ticket to resolve within the next release.

Frequent releases hold you accountable on delivering working software at regular intervals in order for them to see how things are progressing, and in order to make sure you’re staying on task and continuing to capture the vision defined in the requirements.

On Support

A few of my employees at the call center in my basement.

A few of my employees at the call center in my basement.

Once a project is delivered, it’s not done – there’s still the issue of support. I’ve found that it’s often best to discuss this when gather requirements as it sets a level of expectations for the business relationship post-launch of the product.

This looks different for every project, so I can’t offer terribly specific advice, but I can recommend the following:

  • Before accepting a project, know if you’re even interested in offering a support.
  • If you’re interested in offering support, determine if it should be on the basis of a retainer or on a case-by-case basis. Each has their advantages and disadvantages.
  • At the very least, provide the client with some level of documentation and let the know you’re available in the future should anything arise.

Regardless of how much support you offer (or don’t offer), don’t let the client feel as if you’re hanging them out to dry once you’re done. That’s bad business.

After all, they came to you to develop a product for them, and half of development is spent in maintaining a product. It’s not simply building it.

Anything Else?

This entire post was inspired by a number of questions I’ve received from people asking what it’s been like to make the shift to self-employment over the last couple of years.

Some questions have come via email, some via Twitter, and even face-to-face. Regardless, I know that it’s an exciting time to be a developer regardless of the platform, and the WordPress world is no different.

Perhaps the easiest way to distill all of the information down into a single point is to say: Know what your strengths, focus on them, and always keep the client’s best interest in mind.

After all of that, I know that many of you also make a living (or at least a partial living) off of building WordPress-based projects, so I’m all for you guys sharing your advice in the comments.


  1. Matt

    The one thing people should take away from this is in your closing statement: “Know what your strengths, focus on them, and always keep the client’s best interest in mind.”

    I just did a presentation at WordCamp Providence and this one was of my main points if you’re a freelancer selling to a small business. There are too many folks out there, catering to the “$500” budget that are just doing a weak to mediocre job at design and development.

    Probably because in theory, they are neither. They are someone who understands HTML better than your average Joe and has a bootlegged copy of Photoshop wielding the almighty bucket tool.

    I say this, because I use to be one of them. I was your classic flip flopper. To some people I was a developer, to others a designer. In practice, I was neither. I could be dangerous with the loop and could bend stylesheets fairly well – but I never really wore either crown.

    After focusing on what I was good at – business development, consulting, and connecting people I built a team that can do the design and development far better than I could imagine. I’ve been on bit of a rip lately wishing these people from the $500 club would respect WordPress more.

    If you’re not a designer or a developer, don’t put up the front that you are. Certainly don’t hack up a WP install beyond repair and don’t leave your client in the dust. It only makes it harder for the rest of us — doing things the right way — to come pick up the pieces. It’s also dragging down our marketplace for quality work.


    Great post my friend!

    • Tom McFarlin

      In practice, I was neither. I could be dangerous with the loop and could bend stylesheets fairly well – but I never really wore either crown.

      In my experience, this is a large problem that likely won’t be going away. I love the fact that we’ve got people who are passionate about getting into design or development, but the fact is that it’s rare that someone can be absolutely awesome at both – you’ve got to know your strengths and focus on them so props to you for making that shift. Love hearing stories like that.

      Secondly, I also know what you mean about the $500 budgets – I’ve done estimates for jobs before and when they exceed $300, they balk at me. I’ve even been told that they’re kid neighbor would do it for free. SMH.

      People who truly understand the value in hiring someone to good work are out there and do hire. It’s a matter of wading through the mire of those that don’t get it.

      It’s so cliche, but you really do get what you pay for.

  2. Curtis McHale

    I’d make one small ‘exception’ really. I often end up doing stuff I’ve never done before, like today working with Regex and the rewrite API. I’m only barely familiar with Regex and have never worked with the Rewrite API. Should I have skipped the whole project because of 2 hours billable (4 – 5 of reading unbilled) work?

    I think that part of a developers job is solving problems they’ve never solved before. If you just barely know how to build a theme taking on the Rewrite API isn’t a good jump but learning how to build a widget could be within your grasp.

    I always just do the research to see if the concepts make sense for something I haven’t done. If they do, I’m in.

    • Niklas Högefjord

      I agree with you Curtis – I think that taking on tasks that you’re not 100% familiar with is good for your own growth as a developer. This is a profession in constant change. Of course it’s equal important to know your own limitations. It’s not fun banging your head against the keyboard at 3 am, out of frustration over the project… :)

      Thanks for a great article Tom! I see myself as a person with quite good communication skills but reading your article made me think about the way I report the progress to clients in current projects. Have to review that…

      • Tom McFarlin

        I see myself as a person with quite good communication skills but reading your article made me think about the way I report the progress to clients in current projects. Have to review that…

        I think there’s always room for improved communication – it’s one of those things that I try to review at the end of each contract I take on.

        Though I don’t always get a chance, I try to find out if the level of communication was satisfactory or not. If not, what would have made it easier?

        I’ve always received good back when looking for honest criticism.

    • Tom McFarlin

      I think you’re spot on. There have been a few projects where I thought I knew everything I needed to take it on, then I hit a wall.

      That’s not the client’s problem, though, so they shouldn’t be responsible for footing the bill of my time spent learning to accomplish the requirement.

      On the upside, I think most people who are skilled and talented developers are able to research, tinker, and resolve a problem within a relatively timely manner and then carry that learning forward into future projects.

  3. Andrew

    Would love to hear your thoughts on the hosting side of the business too, and some recommendations on the best places to host WordPress sites. Sure, Dreamhost/Bluehost and the like work for the little sites, but what about big sites with a lot of traffic? Should we recommend clients go to a dedicated WordPress provider like WPEngine and PressLabs? Should we master LAMP, Varnish, nginx, Lightspeed, and roll our own VPS or dedicated solution? Should we pass the buck? I often do the latter, and this is where I run into the most headaches. I haven’t found any single place I would consistently rely on once clients hit numbers over 1 million pageviews a month, has anyone else. Thoughts?

    • Tom McFarlin

      I think I could answer this in a post all its own, but I’ll try to summarize it here (and revisit it in a future post) but you probably won’t like my answer :).

      It’s case-by-case basis.

      There are a few gigs that I’ve completed where I’ve put them on a shared host and it’s gone perfect well. There are others where I’ve gone with cloud-based VPS solutions and others where I’ve literally contracted out the hosting to someone else who focuses specifically in that area.

      What’s even more fun is when a site takes off and hosting becomes a moving target – suddenly, shared hosting isn’t footing the bill, but you’ve got to keep the site alive long enough to move it to a new host.

      Hopefully this helps – I’ll see what I can do about publishing a post on this in the future!

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑