We’ve been talking to freelance WordPress developer Bill Erickson. Last time we heard about how he got started in freelancing, became successful and stayed successful. Today we’re going to hear about some of Bill’s freelance best practices.
What are some best practices that help you become a successful freelancer?
My business background was the biggest part of my success. A lot of developers don’t have that and I would encourage them to go learn what they need. I see the feast and famine cycle way too often with developers. When they finish one project they turn around and have nothing to do next. They need to mange their pipeline, schedule effectively and learn to say no.
You need to know the type of projects that will mess up your schedule or won’t be profitable. I say no to 80 percent of what people ask me to do. It’s not always because I can’t do the task. It’s often because it wouldn’t be profitable or would lead to a poor experience for the client based on their expectations.
Analytics is another tool I use. I built a customer relations management (CRM) system on top of WordPress to keep track of prospects, active projects and track data.
Three to four years ago I was finally booked up and I was trying to decide which projects to take. It was a mixed bag. Sometimes I’d have really profitable projects, sometimes a project would drag on forever. How could I predict it? So I started collecting data. I used time tracking programs, entered the price I quoted, the hours I spent, etc. I could calculate the effective hourly rate, sort and see what the characteristics of a good project were.
What I learned is that the smaller the site, the more I was able to make on it. I could quote it more effectively and give more value in less time, which meant I could charge more. So that pivoted my business. Now I’m pivoting toward larger projects.
You need to be making data-driven decisions, rather than going off your gut. Because often your gut is wrong.
Why did you built your CRM system in WordPress?
I tried Salesforce and SugarCRM, but they were asking for info I didn’t care about and didn’t give me valuable analytics. I knew WordPress, so I scrapped the other systems and created a few meta boxes that collected what I thought would work. If I didn’t care about something, I’d delete it. If I found something I liked, I’d add a new one. I change it maybe once a month. It’s an evolving process. By building on top of a tool I know I can customize and make changes, rather than feeling like I’m in typing data I’ll never get any value out of.
While I’ve released my CRM on GitHub, but it was built for me. You’ll have the same problem I had with SugarCRM and Salesforce. Build a tool that collects what you want and let it evolve with your needs.
What is it about smaller sites that you found more profitable?
There’s an inherent value in a website to a business. So regardless of the time you put in to the job, there’s value. At the smaller level, I’m doing more of the same things, so I can increase my efficiency. I can build it faster while delivering the same value. But the more custom it becomes, the more time you’re devoting to this client that you can never reuse. So your value approaches the time you put in.
So the first three hours of a project might deliver $2,000 worth of value. But the more time I put in, you’re getting maybe $200 of value for each hour. So as time increases, the value flattens. I can deliver a ton of value quickly. The more unique your needs, the less value you perceive and more time I have to put in.
But lately you’ve been doing larger sites?
That’s where my business is now going. I priced myself out of the small end. There are too many developers offering the smaller sites. I can do that for past clients who have seen the difference, but many prospective clients can’t tell the difference between an average developer and a good one.
The larger sites aren’t necessarily more or less profitable, but they are harder to scope. The quote is hard to predict. With a larger project the effective hourly rate can be all over the board if you’re not careful. More issues can come up and often do.
For the past year or so I’ve been focusing on larger sites. For instance the University of Cambridge hired me to build a WordPress site that encompasses their new brand, and are rolling it out across 80 different domains. It’s a higher level of WordPress development, really testing the bounds of what can be done with WordPress. They need a senior developer.
I’m currently collecting data on every aspect of the process to deliver better quotes. How much time did I spend on all these things? Document it so when it comes time to quote another project, I know how much I need to charge.
You’ll have an innate feeling—I know this project will drag on, so I have to charge more. You want to turn innate feelings into data points you can do something with, turn it into usable data.
How do you handle scope creep, when clients keep asking for new stuff?
Scope creep is another reason why I tended toward smaller projects. By focusing on smaller projects with a more defined scope I could do better at limiting scope creep.
For larger projects with areas we know can’t be defined, identify those areas and structure your quote appropriately. I’ll use a fixed bid for the defined scope, and time-based billing for aspects we can’t lock down initially.
I built a site for Reader’s Digest recently. We had a clear scope for the most part, for which I provided a fixed bid. But they needed a bbPress forum to replace a custom forum they had built in-house. My quote covered just the installation and styling of bbPress, it did not include any custom functionality, but stated that would be billed at my hourly rate. Once we reviewed the site with bbPress, we could identify what custom features they also wanted developed.
It’s important to identify areas that are clear and identify areas where you can’t have a clear scope and change your quote accordingly.