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:
- Define the scope of the project
- 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.
Amelia Williams
Hi NEMANJA ALEKSIC ,
That was a good lesson. I completely agree with you for the money upfront, but contracts are inevitable too.
Damian
Great post! The only thing I’m missing it’s a simple template or a demo of a contract normally used for this kind of jobs
Nemanja Aleksic
Fair enough, I’ve updated the article with a couple of suggestions.
If anyone’s got a better one, just let me know and I’ll add it to the list.
Mario Peshev
That’s a great post – thanks for sharing it with the world.
I know a lot of freelancers who avoid contracts due to the “unnecessary overhead” and things like that, and I can see the reason behind it for small projects (several hours up to 20h) that could be handled without too much communication. However, larger projects – especially ones with larger organizations with established workflow – simply require a contract.
We use contracts for several reasons:
1) Establish a real business relationship with our customers/partners
2) Minimize the risks of failure and discuss details in the contract – which normally leads to more projects later on
3) Define payment terms – including the upfront payments and iterations
4) State what is included and what is not included in the proposal, which reduces the scope creep in general
5) Use it as a basis of discussing potential extra features later on – or as a constraint to things that would drastically change the original scope
6) Outline expectations for requirements and dependencies (media, content, hosting access, whatever) for the successful completion of the project
7) Set some boundaries and constraints in case of violations – extra fees, payments based on time in case of a mistake by the client, etc – that allows for terminating the agreement upfront with a non-committed client without dragging that for months or worse.
Nemanja Aleksic
I can always count on Mario to share his experience 🙂
You’ve summed it up really well – I especially like the numbers 1 and 7; the former because a contract (or a lack of it) implies the level of professionalism they can expect from you, and latter because time-based payments is something I’ve only recently seen being used by web developers; if you agree to get paid in three monthly installments, you no longer care if the client fails to deliver the content because your fee is no longer tied to the progress of the project.
Jerry Boutot
Contracts are essential. I won’t lift a finger without one, and I require 50% up front and 50% prior to deployment from staging. But even with contracts, the clients can still have an internal conversation with themselves where they believe (or convince themselves) they are getting everything that was ever discussed as hypothetical. For example, I could say during the sales process “once your site is built for SEO and Conversion, we’ll be able to run AdWords ads to see what keywords get traffic to your site then then optimize your content for those keywords. That’s part of our SEO services”. Then they get a contract to build a web site, and nowhere in the Scope of Work does it mention SEO services, but the client might say “you said SEO Services were included”. I’ve had contracts explicitly say “The client will select a Theme for their web site. Custom Programming and CSS Programming are not included in this scope of work.” then have the client immediately ask me to perform major overhaul of the look and feel of the menus, and they’re not expecting to pay. I just refer to the contract, page x section y, and let them know I’ll send a bill for the custom programming, since the contract already states that any out of scope work will be estimated as a change order project, or can be done based on my hourly rate and billed Net 10.
My contracts are pretty lengthy, but you can get away without a formal contract if you specify the scope of work in an email and the client signs off on it. Email is a written instrument, so I rarely rely on face to face conversations or phone calls that result in any kind of agreement without sending the client an email summarizing the agreement, asking them to reply with a “green light” or any changes for things that may have been accidentally omitted from the written scope.
I’m a professional with many, many years of experience building desktop apps and web apps. I specialize now in converting database driven web sites into wordpress, utilizing my SQL skills with custom ETL work that accomplishes disparate data aggregation into incompatible repositories. Pulling data from a database that was custom designed for an ASP.NET and SQL Server application into WordPress requires expertise at the database level not found with most “web designers”. I demand and expect to be paid for my time and expertise, and anyone who wants to call themselves a professional and not just be viewed as a hobbyist needs to act like a business – not like a beggar – and get everything in writing and get paid for what you do. If you don’t use a contract, your clients will never view you as a professional and you will always be on the defensive where getting paid is concerned.
Finally, if your clients don’t pay, fire them.
Nemanja Aleksic
Thank you for sharing your thoughts, Jerry. It seems this subject needs a whole book to cover all the bases 🙂
I need to point one thing that I did not make it in the article:
Contracts are absolutely essential, but things get very tricky when working on the international market. If you’re working for a foreign client, it’s good practice for the contract to determine which court will resolve potential disputes – otherwise you might end up in an uphill legal battle on the other side of the world. E.g. in Serbia, once you transfer a domain from staging to live and the client does not pay, taking down the live site could actually get you jail time.