Baer Business Law – Greater Philadelphia Area – Intellectual Property Law – Business Law – E Commerce – Contracts – Trademarks – Copyrights

Startups like to move fast and don’t have the time and resources for a lot of legal boilerplate and negotiation, much less legal fees. I get that.

Still, if a major part of your business is a website or software application (including iPhone and Facebook apps), it’s well worth the time and (minimal) expense to put in place at least a simple contract with your developers. This contract should get signed BEFORE the developer begins any substantial work on the project

I’ve represented clients rooked by unscrupulous developers, and that is why this topic is heavy on my mind at the moment. And, by the way, this post is not meant to pick on developers. (I represent several very good ones, and it’s in their interest too to make sure there is an adequate contract in place, namely to button down their right to get paid, fix the timing of payments and protect against scope creep.) Still, there are big risks for startups on the client side, which is why a little patience and forethought can avert an expensive derailment of ambitious plans.

Why do you need a properly written contract with your developer?

1. Confidentiality. Ideas have legs — muscular marathon runner’s legs — and you don’t want your developer to walk the idea for your new website or app across the street. It’s difficult to protect still-inchoate ideas and requirements (as opposed to completed designs, specifications or prototypes) under intellectual property law, since bare ideas in the process of formulation are not copyrightable or patentable. Moreover, the allowance rate for business method patents is extremely low (presently under 10%), and the cost of prosecuting patents is typically tens of thousands of dollars, so you should not count on being able to patent your website, program or app even at a more advanced stage of development. What this means is that, besides avoiding disclosures except where strictly necessary, contract protection (i.e., a non-disclosure or “NDA” clause) is your best bet to protect your idea as it is being developed.

2. Intellectual Property Ownership. Even if a bare idea is probably unprotectable, at some point the development of your idea is going to lead to the creation of protectable intellectual property. In the context of web or software development, this could be some or all of the following: (1) code, web design, graphics, images, text and other creative content (all of which can be copyrighted), (2) logos, slogans, catchy domain names and similar branding features (which can be trademarked), (3) look and feel (which is potentially protectable as trade dress), and (4) in rare cases, patentable inventions (if your site, program or app does something new, useful and non-obvious in light of the current state of the art).

It is a widely held but mistaken belief that if you pay a contractor to do something for you, you automatically own all IP rights in the work product because it is a “work made for hire.” (In fact, even attorneys often make this mistake, as I was reminded when I was a reviewing an IP asset purchase agreement drafted by opposing counsel the other day.) “Work made for hire” is a copyright concept only; furthermore, with outside contractors, it applies only to select types of specially commissioned works like atlases, parts of motion pictures or other audiovisual works, tests and instructional texts, which are generally irrelevant to the context we are discussing — and even then, a written agreement stating that the works are “made for hire” is still required!

In plain English, what all this boils down to is: you don’t own it (even if you paid for it) unless there is a contract that says you do. To be legally effective, the contract must also assign all relevant copyrights, patent rights and other IP to your startup. Without such a contract, you only get a license (i.e., a narrow right to use), the developer still owns any copyrights and patents, and it is free to use or commercialize this IP elsewhere. Potential investors and acquirors looking at your startup will want to see that you have IP ownership buttoned down. If you don’t own your product, watch out.

3. Getting What You’re Paying For. In development parlance, this refers to scope and specifications: you are paying X for the developer to build you Y, with Y being fleshed out in as much detail as possible in the contract. The importance of getting this nailed down is best illustrated by a common horror story: Client goes to Developer and asks Developer to build a site with A, B and C features and functionality. Developer says sure, no sweat; it’ll cost you $5,000, half up front and half on completion.

Developer labors for a month before realizing that he seriously underbid the project, which is far more complicated than he had considered. So he stops work and informs Client: sorry, I can’t possibly make a profit on this deal, but because I’m a warm-hearted stand-up guy, I’ll agree to just keep the $2,500 you’ve already paid, even though I’ve done $6,000 of work. For this largesse I welcome any comparisons to Gandhi you care to make. Client, who is out $2,500 and doesn’t have a website, is not inclined to award any Nobel Peace Prizes.

Developers may cry foul at this narrative. The common argument I hear from developers is that clients think developing a website is like rehabbing a bathroom, i.e., the client knows what it wants and parameters of the project are fixed at the outset, so there is no scope creep. In contrast, the argument continues, development clients actually DON’T know what they want. Their requirements are constantly in flux, and they require endless rounds of revisions.

Fair enough. But this doesn’t undermine the case for a contract. Quite the opposite, it means a contract is urgently needed by both parties to manage expectations. The contracting process is an opportunity for both sides to crystallize and refine those expectations before money is spent — what will the basic functionality/features be? what platform will the site run on? how many rounds of revisions are included? what will additional revisions cost? And so on.

The idea is that scope is reduced to writing as much as possible at the discussion stage instead of during the thick of development (and ideally a process is defined to handle any requested changes in scope). If it is impossible or impractical to draft detailed functional specifications at this stage, they can be a deliverable to be approved by the client later. (For complex or expensive sites or programs, the parties may end up splitting the risk by handling functional specification development and actual coding as two separate projects, each covered by its own scope definition and cost parameters, with the client having the option whether or not to proceed to stage 2.)

4. Getting It When You Need It. Launch is everything to startups. If a site or program isn’t ready or isn’t debugged by the time desired, this creates all sorts of risks — risk of the competition getting a jump on you, risk of seed capital running out, cash flow risk if an expected stream of revenue is postponed, reputational risk if you’ve heavily promoted the launch and then have nothing (or nothing respectable) to launch. A well-drafted development contract, therefore, should include key deliverable milestones along with delivery dates, and payments should be tied to successful achievement of these milestones in order to incentivize developer performance. A meaningful portion of the development fee (a third or more) should be payable only after final delivery and successful completion of user acceptance testing.

5. Legal Stuff. This is the part that startups really hate, but it can be critical if a dispute arises (as it frequently does). Say a Philly client hires a developer in California to build a site for $10,000. The parties sign a contract, and the developer takes the client’s up-front payment of $5,000. The developer then absolutely does nothing and greets the client’s increasingly anguished entreaties with an upraised middle finger.

It doesn’t take a tech lawyer like me to tell you the developer breached the contract. But how does the client left in the lurch get a remedy? The contract says nothing about where disputes will be litigated (venue) or which state’s law will apply to the interpretation and enforcement of the contract (choice of law). The answer is that the client hires a California litigator at $500/hr to fight over these issues, as well as over the underlying breach-of-contract issue, and after spending $100,000+ in legal fees (and traveling to California to testify), after three to five years the client may get its $5,000 back or perhaps a court order forcing the developer to finish the site.

Obviously this is a losing economic proposition for any client, and it would be insane to sue, despite the legal merits of the case. On the other hand, let’s say the contract had provided that the law of enforcement would be Pennsylvania’s, that any litigation must take place in Philadelphia, and that the party prevailing in any litigation would be entitled to be reimbursed for its legal fees, in addition to any recoverable damages. The costs and risks of enforcement are now working in the client’s favor; it can now bring the suit in Philly, representing itself pro se if necessary, and force the wrongful party (the developer) to pay both sides’ litigation costs, which is a big stick indeed. Of course, there may still be reasons why litigation is not advisable (for example, the client would still need to get a California court to enforce the Philly court’s judgment, and the developer may not have sufficient assets to pay the client’s legal fees and damages, which defeats the whole purpose). However, the client’s ability to raise at least a credible threat of litigation, together with the possibility of much higher costs for the developer, thoroughly changes the dynamics of the dispute and gives the client greater leverage.

Avoiding the 15-Page Monstrosity

If you think that adequately addressing these considerations requires a 15-page contract which would take months to negotiate and consume thousands of dollars in legal fees, you’d be wrong. All of this can be easily hammered out in relatively simple language taking up a couple of pages. Legal fees should be minimal if you’re dealing with an attorney who knows technology and is used to working with startups (otherwise, you may very well get the 15-page monstrosity).

Your startup doesn’t need a perfect agreement with every conceivable bell and whistle; the perfect should never become the enemy of the good. But the basic issues I have described need to be covered. It’s no exaggeration to say that the costs of not obtaining basic protection, in terms of both money paid out to developers and lost future opportunities for your startup, are likely to vastly exceed the legal fees.

And, developers — this is for your own good too. Think about helping your clients by creating a simple contract template with some moderated version of these basic protections for the client built in, along with protections against scope creep and whatever payment terms you need for your business. Contrary to popular belief, contracts aren’t just (or even primarily) for hypothetical future litigation — if drafted well, they are litigation-preventers and value-enhancers, allowing projects to glide to completion along a pathway of smoothly aligned expectations.