Getting Paid: A Web Developer Nightmare

A long time ago a friend of mine asked me to team up with him for a web development project. I was young, dumb, and the money was good. The project was for a company that occasionally hired my friend for some freelance work, and according to him, “they were great both as people and as professionals.” So I said “Sure – you trust them, I trust you; let’s do this.”

Big mistake.

Or should I say, the first of a series of big mistakes. You see, I let my friend handle the project management, which meant he had a lot of face to face meetings with the company, but there was no paper trail and no contract.

The project kept getting delayed, months after it started. There were still some fundamentals that haven’t been determined; the copy was absent, as well as a large chunk of the website structure. I’ve all but forgotten about it when I got an email from their CEO, asking why it’s taking so long to complete their website. We had just barely enough email correspondence to cover our butts, when the CEO casually mentioned multilingual support; we had no idea what she was talking about, and of course this wasn’t the scope of project. We were still reeling from the shock when she dropped the bomb: “This is taking way too long, and with the new website being delayed, we’re taking a financial hit so we’ll have to cut the budget by 30%.”

We ended up walking away from the project, but to this day I am thankful for the lessons I’ve learned from that mess.

Get a Contract

If you don’t have a contract, you’re a web development amateur, not a professional. Trust and good faith are awesome if you’re starting a lemonade stand, but they hold no weight in the business world. A contract is the only thing that will guarantee you’ll get paid. This is the only wisdom you need, but if you want to hear more, Mike Monteiro held a great talk where he brought his lawyer to lay down the contract fundamentals in person. As much as we hate lawyers, they are a necessity in today’s world, and you can be sure that the other side will have one when the chips are down.

Now, I’ve been in a lot of situations where a contract was not an option, usually because the client refuses to sign for one reason or another; you really need this gig to keep the lights on, so you’ll take the job without a contract. No worries, there are still ways to protect yourself, if you pay attention to two main factors:

1. Define the scope of the project
2. Get paid before each stage of the project

Defining the Scope of the Project

Our company holds talks and workshops all the time, mostly for high-school and college kids; sometimes we hire outside experts when we’re pressed for time. Just the other day we had a problem with an expert doubling his figure after he accepted to hold a dev course. Both parties were at fault because we haven’t actually sat down and defined his scope of work and the corresponding fee – instead we acted on good faith. The worst part is that there was no ill will on either side; imagine how bad it can get if one party plans to screw the other over.

You need to first settle on the amount of work you will be doing for your client, and the corresponding fee. This is very important, because down the line you will inevitably get additional requests, ranging from minor website design tweaks, all the way to completely new features.

You need to protect yourself from that. If it’s really a minor feature, you can let it slide. But if the client wants a whole new page with lots of bells and whistles, treat it as a new project – make it clear that you will be happy to do it once your original project is complete and your fee has been paid in full. Project tweaks are a slippery slope; by the time you realize what’s going on, you’ll already be neck deep in a completely different project than what you signed up for.

Getting Paid Before Each Stage of the Project

You’ve waived the protection a contract would give you, so the only bargaining chip left is your own work. Protect yourself by splitting the project into several stages, and tying a payment to each of them. I usually do it in four stages:

• Our proposal is accepted, a 30% deposit is paid by the client.
• We start working on the design.
• The design proposal gets the green light, another 30% is paid by the client.
• We start building the website.
• The website is complete, after we get the final 40%, we deploy the website from the staging area to the final destination.

This approach is great for a number of reasons: the client demonstrates his commitment by sending you some of the money up front. If the project falls through, you’ll still get some of the money you worked hard for. The client can backtrack at any time, but will need to pony up the money again for the previously completed work. And remember – always keep a paper trail.

I’ve tried covering the basics of what you can expect as a web developer in this big bad world. Do you have any quality tips you’d like to share with other developers? Do you use contracts, or do you outsource debt collection to mafia?

UPDATE: I’ve added a few resources for web development contracts for your convenience. Each country has different laws, especially when it comes to Intellectual Property. If you decide to create a contract template for your future work, have a local lawyer go through it. And if for any reason the client brings a legal representative into the negotiation, I strongly recommend hiring one as well – these people are paid good money for a reason, especially if you’re working on a major project.

RocketLawyer.com has a great contract builder for US web development contracts. The’re not free, but there’s a 7-day trial so you can cancel before you get charged, or you can pay a flat $10 fee.

Contract Killer on GitHub is too informal for my taste, but it covers all the bases well, it’s free, and there’s a good chance that non-English speaking people will find a localized fork (there are 900 forks so far).

Bidsketch is my pick of the litter because it’s professional looking and free.

I also recommend Joyce Grace’s article on the process of creating web development contracts – it’s of great help if you are not sure yourself what the contract should include.