Trust Me, On Paper

Is this the face of someone you can trust?

Of course it is. It’s me! You’ve met me a few times, or maybe you heard about me from someone else who really, really likes me. Maybe that person has worked with me before, or maybe they know me from somewhere else, but they heard I was great. Or at least they assume I’ll be great. After all: doesn’t that face look friendly and trustworthy?

The truth is, I really am friendly and trustworthy, but if you are a first-time client working with Jebraweb, you really don’t have any proof of that. I’ve heard some real doozies about deadbeat web consultants that give people like me a bad name. Some of them build great systems that they never train their clients to use. Some of them are responsive during the initial project but don’t ever return their clients’ calls and emails later. Some of them offer to do things that they don’t actually know how to do, then fumble their way through them later and make big mistakes that cost time and money from everyone. In one instance, I even got a job from a client whose database developer had literally run off on a cocaine binge and they couldn’t find him. What?! It’s true.

So, even though I wouldn’t do any of those things, I don’t expect everyone to trust that I’ll do what they want with their web project for the price they expect by the deadline they need.

No one should enter into an agreement based on “I promise.” Large companies and non-profit organizations accept this by default and insist on something more than a handshake, and even if you’re a teeny tiny private company or a half-dozen-employees non-profit, you should rely on this crucial one-word rule:

C-O-N-T-R-A-C-T

That’s right: you always, always need to sign a contract with your web development firm. That contract should be clear on the following:

1. What is the web developer contractually obligated to deliver to you? Don’t say “a web site,” because as I discussed in my last post about estimates, that encompasses a lot of components. The list of “deliverables” may include setting up a content management system and training you to use it, inputting all your content, editing and inserting photos, building a contact form, integrating social media buttons, including an online calendar, and dozens of other “add-ons” that should be listed. This protects you from getting a blank web site with your name in the header and a bill from the developer, and it protects the developer from being sent a thousand requests for things to add to the site he’s already agreed to do for far too little money.
2. Where will the site be hosted while it’s in development? Surely you’ll want to see the site while it’s being built, at least in draft format. Is it living on your developer’s laptop, on his/her own hosted web site, or in a hidden folder of your web site?
3. When is the work being done, when will it be complete, and what do you need to provide at each point in the development timeline? Do you need to send anything to the developer before work can begin? Is there a clear deadline written in the contract? Is all the work scheduled to happen at a time when you and your staff will be available to answer questions the developer might ask? That last part is especially important for schools and other organizations that tend to have large numbers of staff all out of the office at once.
4. Are there any costs your developer will incur on your behalf for which s/he will bill you later? Recall that even open-source software, which we use, can have commercial extensions that cost something. Other expenses could be related to hosting or other items your developer may think are matter-of-fact but which you did not see coming. If it’s in writing from the start, you know what you’re buying, even if it’s just your developer’s commuting costs to on-site meetings.
5. What happens if the scope of the project changes? In even the best, most carefully considered project plans, something can come up that you want to add to the final product. Maybe you saw something on another site that you absolutely love and want for your site, or maybe you misjudged how much you would like the free photo gallery and now you want your developer to configure a much prettier — but more complicated — online photo gallery with a lightbox. Will the developer inform you of any additional labor cost? The contract should clearly explain how the developer will communicate and receive your agreement to an increase in project cost.
6. What are the terms of payment?  This varies a lot among developers. Some require a percentage of the project cost at contract signing and the remainder at the site launch. Some will bill you monthly for the hours they work. Some are flexible about this. There’s also the question of what forms of payment are acceptable — credit cards, check, cash, PayPal — and it’s a very tough surprise to assume you can put your web site on your Visa, only to discover after you get the first invoice that the developer only accepts wire transfers to an account in Mali.
7. Who owns this web design? On this, I have a strong opinion. I think you should own this design, since you’re paying for it. That said, this should be explicitly mentioned in the contract.

Basic contracts also usually include a bunch of legal language about the state in which this business is being conducted and where any potential related lawsuit should be litigated; an assurance that the developer is carrying current liability insurance; a non-disclosure statement in case your developer will come across any information they could sell to your competitors; and several other things. You should absolutely contact your attorney if you see anything that makes you go “hmmmm…,” and if you have the means, it’s probably a good idea to have your attorney look over any contracts you sign, just as a matter of course.

I want to make clear that I am not giving you legal advice — I’m not an attorney by any stretch. These are all my suggestions for the types of things that I have found can save a lot of irritation and confusion during the course of a development project. Whether you are hiring Jebraweb, your neighbor, your cousin, or someone who responded to your RFP with a great proposal, you should be able to set clear expectations in writing, on printed paper, with ink signatures from both of you, and then file it in your desk drawer. The formality of the process makes everyone take it seriously, and then you effectively have a checklist to use to track the progress of the site’s development.

By all means, go ahead and trust me — after we put it in writing.