I recently had a good sense to add this new boilerplate section to my standard project contracts:
3.5 RIGHT TO DEMAND SATISFACTION
Acceptance of this agreement includes the right to demand satisfaction for all described features, no more, no less. I’m on the hook to complete all the described features to the point that you love it, and you get to demand satisfaction to that extent. So do it. If you’re not happy, and you haven’t exercised this clause, you’re technically in breach of this agreement. Just sayin’.
In my years of experience I have never been burned putting myself on the hook called “my work is not done until you love it” , so I realized that I may as well get the benefit of advertising as much up front.
I don’t know that this sort of clause exists anywhere else in my industry. Flippant language aside (which in my estimation is rad: if that sort of playfulness backed up solid performance turns you off, you’re not my client anyway), I think there’s a general fear about having to appease some fictional, nightmare client who is endlessly demanding. In my experience, when it comes to my world of web programming, they don’t exist1. Oh sure, there’s always room to want more features, or a cheaper price, but that’s not what what’s on the table here.
This here is a promise to do great with all of the [meticulously outlined] features within the scope of work at hand. Software development is generally a complex endeavor so I think the average bear understandably shies away from such a tall promise. Fair enough. I embrace it. It keeps me honest and fosters a healthy pride in my craft, and if I just bring my art to it using my full facility with leading edge technologies and tricks, I don’t have to worry about falling short.
So I don’t fall short. If my first attempt isn’t loved by my client, they tell me and I tweak accordingly. No fuss, no muss2.
That’s the second beauty of stating up front the right to demand satisfaction: it creates a conversational dynamic between my client and I that deliberately CALLS FOR that kind of feedback. We become partners in the endeavor to create software that perfectly suits, and they have a role to play called “speak up if you don’t love it.” When the invitation to do that is clear and on the table it is easy and fun to exercise, and moreover doesn’t get compromised by a desire to be polite.
- This is assuming a contractor is only taking on work that is within their ability to deliver, which is, it turns out, not to be overlooked nor taken for granted. ↩
- If I think it’s easy to build software to be loved on the first pass, it’s really easy to do armed with feedback from looking at a real, tangible first attempt ↩