Why I’ve Walked Away from $100,000+ in Web Development Work (So Far)

In the web development world, I get a lot of new entrepreneurs approaching me with “the big idea.” Many of these people have a fair degree of business experience, so our talks usually begin with a Non-Disclosure Agreement (NDA). This is standard in business and, in fact, I have my own NDA that I send to them. It basically states that they can safely tell me their idea, and I can’t steal it. Fair enough; I’d do the same if I needed to find contractors for my own field of dreams.

Once discussions get going and we’re getting close to a deal, there’s the matter of getting a contract signed. This is where, no matter how great of a fit both parties feel exists, things can deteriorate. In my line of work where we specialize in one thing — web development — I’ve long felt that it’s better to be the issuer of such contracts vs. being the recipient. This isn’t some kind of business trickery or underhanded tactic; it’s purely practical. If I’m having to manage web work for hundreds of clients, it’s simply better for me to have a standard contract that all of my clients sign than to have 100 different contracts that I sign from them. That’d be a nightmare for me!

It’s similar to if you join a gym… you sign their agreement; you don’t just bring your own into the gym and say here’s what we agree on. So, there’s an appropriate issuer and an appropriate receiver in business situations.

That all said, I used to work in contract law, albeit peripherally as an editor, and absorbed a few key points, one of which is that all parties in a legit contract should have a certain degree of say-so in a negotiation. Those standard 100% “take it or leave it” jobs aren’t always enforceable for that very reason. (Here’s a link to Cornell Law School where you can read some basics, if interested in what a “contract of adhesion” is.) So, yes, my contract provides for what I believe is a reasonable amount of such negotiation.

When it comes to “the code,” this is where I find a few specific types of potential clients. In the “completely unreasonable” column, I would place those clients who insist that they “own” every line of code involved in a project. Now, granted, most of them don’t know how to code, or can define what is and what isn’t ownable — not to mention the complexities of an environment in which we’re also using open-source code, third-party code, and god knows what else in the mix. But, these clients are of the opinion that if we write “$x=1” in a script, then we technically can’t write “$x=1” for any other clients, forever.

The paranoia at play here is, “Hey, I dreamed up this great system for packaging widgets, so what’s to stop a web developer from stealing that system and selling it to our competition?”

Well, for one, there’s the confidentiality clause that’s also in our contract. If Client ABC has some ingenious marketing approach that’s non-public, and we’re hired to do some kind of web-based automation or integration of that, we literally cannot do anything with the knowledge of such an approach, other than to be impressed by it.

That said, let’s say that the above process involves our taking information in via a web form. And, within that form, maybe there’s a field that requires us to take a long decimal like 3.14159. Let’s say that, in our history of working with form data, we’ve never had the need to take in decimals like that and store them in the database properly. So, we do this work for Client ABC, and we get it working as needed.

The Problem:

Then Client XYZ comes along later — totally different industry, totally different purpose for their form, but wow!, they also need to take in numbers on a form like 123.45678. So, knowing what we know from our work with Client ABC, we apply the same, or similar, code to Client XYZ, and get their form working, too.

This is a basic example of how technology, and code in particular, can be “shared” yet also *not* be competitive at all in nature. Each time a developer learns how to do something over his or her career, that knowledge goes into a virtual toolbox of solutions. Each new client adds something to the toolbox, and each new client benefits from ALL of the previous clients. So, if you view the above process as unfair to Client ABC, then you’re missing the point that Client ABC also benefited greatly from *all* clients that came before ABC.

Now, while I hope the above shows why we will never sign off on something that says that the client “owns all of the code,” it’s also true that other development companies take the opposite approach; they may say that the *development* company actually owns all of the code, and that the client has zero rights to it. There are some good arguments for this, too, but I won’t cover those here.

In my company, really just for our own sanity and not wanting to deal with problems or having to manage rights on code for scores of clients, we take a middle approach. Our contract states that we “grant to Client, and Client hereby accepts, an unlimited, unrestricted, royalty-free, fully paid, worldwide and nonexclusive use (unless such rights are specified otherwise within the scope of work).” (This is very much based on the same philosophy as the Creative Commons approach.)

What does this mean? Well, it means that we can add those kinds of lessons learned to our toolbox to benefit other clients, just as everything in our toolbox will benefit the current potential client. But, no, it doesn’t mean we can, or even would care/dare to, appropriate business trade secrets, as is clearly stated in our confidentiality clause. It’s a distinction I hope is articulated here a little more clearly now, but I do welcome questions, if any current or potential clients have any.

Truth be told, there are a few more observations here. First, 99% of clients wouldn’t know how to even view code, or understand what it’s doing, anyway, not to mention the near impossibility of enforcing such a thing. So, I’m not sure that any of the above holds almost any relevance at all to business owners. They mainly want functionality, and aren’t looking to have some sort of proprietary technology developed. (Granted, there may well be some who are looking to patent something, or something like that, or who are working with lawyers who are making specific demands. So, yeah, those clients are not for my company, in general. I would say that, if a client *did* insist on “owning” such code, could define that properly, and we were amenable to it, then our rates would at least triple, if not much more and possibly would include some sort of equity provision — and that’s on the off-chance that we would even be interested.)

But there’s also pure trust and reputation, at least with my company. For example, we’ve never found ourselves mired in a legal battle of any kind in my 20+ years of web work (at least, as of this writing, anyway, but hopefully this statement will remain true forever). I’ll admit that there’s potentially some kind of grey area herein that I’ve not addressed. That’s where clients can leverage reputation. Look us up, or look up your own developer’s online presences — LinkedIn profiles, recommendations, references, etc. Not all businesses can offer that as assurance, but if a business can produce those items, then that says a lot, too.

Sometime soon, I’m going to write up a ton of articles on the topic of web development contracts — what the various provisions mean, why they’re there, and our take on them. I consider sharing this information to be a service to the business community, and look forward to getting to that. For now, back to coding. :-)

Jim Dee heads up Array Web Development, LLC in Portland, OR. He’s the editor of “Web Designer | Web Developer” magazine and a contributor to many online publications. You can reach him at: Jim [at] ArrayWebDevelopment.com. Photo atop piece is original — an antique tile I photographed in (I think) Lisboa earlier this year. It looked to me like a guy saying “no thanks.”