Freelance WordPress Developer Bill Erickson Part 3: Billing & Contracts

We’ve been talking to freelance WordPress developer Bill Erickson. Previously we heard how Bill got started and he shared some of his freelance best practices. Today we’re going to hear more best practices as Bill shares how he handles billing and contracts with his clients.

Can you tell us about your unique billing system?

For all my projects I require 25 percent down to get it on the calendar. When the project starts I invoice for the remaining 75 percent, due one week after the project is ready for review. So if it takes three weeks for initial development, payment is due in four weeks. I tie it to the start so it’s tied to a deliverable on my end. I’ve put in 90% of the work so far and you’ve seen it, so it’s your turn to put trust in me. If you’re waiting for the site to go live for final payment, it can take quite a while to get paid, and there’s not much you can do to speed it up. I have sites on my server that have been there for a year as clients tweak content—I don’t want an invoice tied up in that. It motivates them to get their work done. On larger projects we’ll break it down with larger milestones, so functionality is reviewed on certain dates. But payment is always based on a deliverable on my schedule, rather than a client’s deliverable such as approval. You’re aligning motivation. If they know that once it’s approved they owe you $5,000, they’re less motivated to approve it. If they’ve already paid for the site, they want it live as soon as possible and are more likely to accomplish their tasks. Once final payment comes in, then the site can be launched. Once the site is approved and migrated, they have 10 days to identify any migration-related issues. After 10 days, the project is complete and I remove it from my development server. Further changes are billed on a time basis.

How do you handle contracts?

I’m a little different than most developers because I don’t use super legalese contracts no one understands. I see the purpose of a contract as setting expectations—it says what I do and what you do. This is a document we refer to throughout our project. If I send a site in for review and they say something isn’t there, we go back to the contract to see what it says. If you make the contract overly complicated, the client won’t read it and there could be misunderstandings.  My contract is an email, it explains the scope of the work, gives payment terms, timelines, and other topics that I find important to have in writing. I’ve had a few clients not pay me and I could have sued them, but it’s not worth it for a $2,000 project. I can sacrifice a little legal security with the few clients who won’t pay in exchange for better understanding and communication on my other projects. I’m definitely in the minority on that end. I know high-end developers all have really big legal contacts.

Does that approach to contracts work for the bigger projects?

For my larger projects, the clients typically have a contractor’s agreement I have to sign anyway, so this is more of a functional document, the one we refer to throughout the project. I go through their contract and make sure it matches the terms of mine. They often want to own copyrights to everything, so I include a GPL statement:

“WordPress is an open-source project. The code we use to run your site has been freely developed by thousands of developers. If I develop any useful piece of code that can be generalized and used to further the WordPress project, I will contribute it as a tutorial, plugin, or patch to WordPress core. However, I will never resell or give away the code to your website in whole to another party.”

Most clients don’t have a problem with it once you phrase it like that, and it’s important to agree to this before you start developing. Lawyers don’t like it though. I once had a contact that said I couldn’t use GPL software— it was a WordPress site so we had to update their contract. I’ve never had a client have an issue with that. When I say I’ll never give away the full site or code to a competitor, they’re happy. They hired me because they saw what I’ve done through my contributions to the WordPress community. That’s part of their purchasing decision. If they hired me because of all this stuff, they won’t ask me to stop.

Next time Bill will share how he gives back to the WordPress community and how he grows his business.