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
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.
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
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.
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.
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.
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.
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.
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.