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

What you get with a solid developer contract

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.

A radiant weekend in the Old City

1. Entity Formation. Choice of entity is key. Find some sort of limited liability structure that gives you pass-through federal tax treatment (i.e., the entity’s income passes through to your personal tax return rather than being separately and duplicatively taxed). Either an LLC or an S Corp. would qualify. And don’t think you have to incorporate in Delaware. Pennsylvania has made a conscious effort to compete with Delaware for incorporations, and it’s really cheap and easy to form and maintain an entity here. The Pennsylvania Department of State Corporation Bureau has a website which allows you to check the availability of your desired business name and obtain the forms needed to start the business. It costs $125 to incorporate an LLC or corporation in Pennsylvania. Personally, due to the minimal registration fees, taxes and paperwork involved, I like the Pennsylvania LLC, assuming the business is headquartered here.

If you have or expect to admit partners into the business, you should have an LLC operating agreement addressing such issues as voting rights, management responsibilities, transferability of membership interests, allocation of income and losses, etc., but if it’s just you in the business for the time being, this is not critical. The bottom line is that for a small, relatively simple web startup, entity formation issues shouldn’t cost thousands of dollars in legal fees.

2. Trademarks. You or your attorney should do a quick trademark search in the searchable database on the U.S. Patent and Trademark Office website (go to www.uspto.gov and click on “Trademarks”) for the name of your business or website and any prominent catchphrase or slogan you plan to use on the site. What you are looking for are trademarks or applications for trademarks that are the same or similar to your mark and are used (or applied for) in connection with similar goods or services. This is a rough approximation of the legal standard for infringement of trademark rights (”likelihood of confusion” between two marks based on the two key factors cited above, as well as other factors like similarity of commercial impression, sophistication of target consumers, overlap of channels of trade, etc.). You should also run Google searches to identify similar terms and business names, since it is possible for another business to have “common law” trademark rights in a mark even if it isn’t federally registered.

The point of this exercise is to gain some comfort that you won’t be infringing someone else’s trademark, in which case you could be liable for damages (possibly treble damages and attorney’s fees for willful infringement) and would have to change your mark and/or domain name. The searches and analysis shouldn’t use more than a few hundred dollars of attorney time, unless the searches reveal a number of potentially problematic third-party marks and you want your attorney to investigate all of them in order to refine the risk assessment.

If a lot of money was being invested to develop a brand, you would want to perform a more rigorous (and expensive) search that would cover state trademark, business name and fictitious name registries, as well as additional “common law” sources like databases of publications, but this can cost thousands of dollars in attorney time and third-party search agency fees. A quick and dirty “knock-out” search of the type I have described should suffice for a small web startup without much seed capital.

You should also think about filing a trademark application to protect your rights in your mark against third party users, assuming that the searches of the USPTO trademark database and the Internet searches uncover no other marks that are confusingly similar, and that your mark is “distinctive,” i.e., is not a generic term for or descriptive of your goods or services. As of September 15, it will cost $375 to file a trademark application per class of goods or services ($325 if you file electronically), and each application should cost no more than $200 of attorney or paralegal time (excluding trademark search costs), unless you are applying for a lot of different goods or services. (To limit attorney and filing fees, talk to your attorney about what goods/services you should apply for now and what can wait.).

Of course, if the Trademark Office rejects your application, and you want your attorney to respond to their objections, this means more legal fees. If the Trademark Office is objecting to the mark itself (on descriptiveness or likelihood of confusion grounds, for example), rather than to some technical aspect of your application, the fees could run an extra grand or two, since your attorney will have to perform research and prepare a short brief. Having said that, you can always abandon the trademark application if it becomes too costly to proceed. Also, a good trademark attorney will be able to anticipate these types of objections at the search stage, so you should ask about your chances of actually obtaining a registration before you file the application.

You are not required to file a trademark application to use a trademark. You only need to do this if it’s important to scare off (by obtaining powerful legal remedies) third parties who may want to use the same or a similar mark. Investors will want you to register your key marks (such as your website name), but this is certainly not something that must be done prior to launch. If you decide to wait to file a trademark application, you should still make sure you place a TM (or SM for “service mark,” if you are offering services under the mark) superscript by the first prominent use of the mark on your homepage and in any marketing materials for the site.

3. Copyrights and Copyright Licenses. Website code, content and design are all copyrightable if they reflect a modicum of creativity and are not purely functional. Copyright comes into existence once a creative work is written down or recorded, i.e., you do not need to have a Copyright Office registration to own a copyright. Registration is necessary to exercise legal remedies against infringers, but again, this is something you don’t need to worry about right out of the gate.

What you do need to worry about right away is making sure you have the proper rights in all code and content used for your website. By “proper rights,” I mean owning the copyrights in materials designed or developed specifically for your site (HTML code, creative, look and feel, etc.), and suitably permissive license rights in third-party content (like clip art, stock photos and music) used on the site. With respect to the first category, specially created materials, keep in mind that the author (i.e., the programmer, web designer or web developer) owns the copyright unless he or she transfers it to you by written assignment. Therefore, without a signed development agreement or copyright assignment containing the necessary language, you get only a limited license to use developed materials, and the developer can do basically whatever they want with them or give them to someone else.

Do NOT, therefore, have someone design or develop a website for you without some sort of written contract. Investors will want to see that you own the copyrights in your site and have the documentation to prove it. The last thing you want to have happen, once your site becomes a success, is some third party come out of the woodwork claiming that they are entitled to royalties or demanding a right to consent to a planned sale, modification or exploitation of the site. An attorney can help you with this process. A simple copyright assignment should cost you $200 or less.

With respect to third-party content, make sure you read the license agreement to confirm that your planned use is within the scope of the license and there are no nasty surprises. (Of course, to do this you first need to make sure you HAVE the license agreement.) Don’t assume that because music or an image is lifted from a “stock” or “royalty free” source you can do whatever you want with it. For example, some “royalty free” licenses prohibit use of the licensed image for commercial websites or in promotional materials. You can take the first stab at looking at the agreement or agreements yourself, and bring in your attorney if you have questions. Make sure that any web developer or designer you use understands your concern about third-party licenses, and if you have a contract with them, the designer/developer should warrant that all content is either original or comes with license rights sufficient for you to operate and use the site for its intended purposes.

4. Other Contract Issues. Depending on how much you are willing to negotiate with your web developer or designer, you may also want to include additional safeguards in the contract such as business and functional requirements and specifications, acceptance criteria, milestones and deadlines, caps on fees, etc. If you are on a tight time schedule, think about negotiating a holdback of 1/3 or 1/2 of total fees until the website has been completed and you have verified there are no major outstanding issues. Again, this is not a legal requirement, just a good idea. A simple one or two page contract (which would include an assignment of copyrights) should not cost you more than a few hundred dollars in legal fees.

5. Website Terms of Use and Privacy Policy. If your website is in any way interactive, you should have legal terms of use and a privacy policy (indeed, the latter is required by the Federal Trade Commission and some states’ privacy laws if personally identifiable information such as name, address, e-mail address, Social Security or driver’s license number, and/or credit card or other account numbers are collected on the site). Contrary to popular opinion, not all terms of use and privacy policies are standard boilerplate.

With regard to terms of use, the legal risks and issues involved in a social networking site, a financial services site or an online store for power tools are going to differ from those for a passive site where users can coo adoringly over snapshots of puppies. In addition, a site that invites the submission of user content, such as blog posts, photos or videos, will need to have a Digital Millennium Copyright Act take-down policy to immunize the site operator from copyright infringement liability relating to content posted by third-party users. To be truly protective, the terms of use must be tailored to these risks and issues. Also, keep in mind that some legalese can scare website users (as Facebook learned to its chagrin earlier this year when its terms of use briefly stated that Facebook would own content that its users uploaded onto the site).

As for the privacy policy, you should think beforehand about (1) what types of personally identifiable information you will collect, (2) with what types of third parties (service providers, marketing partners?) this information may be shared, (3) what types of uses you foresee making of personally identifiable information, and (4) how, if at all, cookies, pixels and flash objects will be used on the site to collect information from users and how such information will be used and shared (e.g., will the information be shared with marketers or advertising networks for behavioral advertising?) Obviously, these decisions are partly cultural — how much comfort do you want to give your website users on privacy? If you have thought carefully about the specifics of your privacy regime (how information will be collected, used and shared) before having a conversation with your attorney, this will reduce your legal fees. If you plan to collect personally identifiable information from international users on your site, you should also bring this up with your attorney, since the European Union has much stricter privacy laws than the U.S.

Depending on the nature, features and complexity of your site, drafting the terms of use and privacy policy may mean spending anywhere from a few hundred to a few thousand dollars on legal fees. In my humble opinion — and I may be ducking rotten tomatoes from my fellow bar members for saying this! — it should not cost more than this, unless the site is extremely elaborate (Amazon) or the client extremely picayune. With that said, however, sites that offer highly regulated or controlled products or activities (such as online gambling, liquor, health supplements, contests or sweepstakes) or are targeted at children may also require additional disclosures (e.g., contest rules) or controls (e.g., a process to obtain parental consent for the collection of personal information from children under 13) beyond the terms of use and privacy policy, which, of course, will cost extra.

Painful as the legal fees may be, terms of use and privacy policies fall within the old adage, “An ounce of prevention is worth a pound of cure.” They are necessary shields against legal and regulatory liability. Additionally, with the FTC, in particular, sounding off on how certain behavioral tracking disclosures (among other things) should not be buried in legalese and also getting cranky about ways websites should notify their users about material changes in terms of use and privacy policies, you need to have these documents drafted by a pro.

6. Web Copy Review. Your attorney, who is probably thirsting for billable hours in these grim times, would love nothing better than to take a red pen to your site copy and etch out every conceivable source of risk. For most sites that are launched with little seed capital and do not feature heavily regulated or high-risk products or activities (gambling, liquor, financial services, sweepstakes or contests, material targeted to children, etc.), this is probably overkill. Having said that, it is a good idea to have a business lawyer with some experience in online promotions do a quick, high-level pass through the site to see if there are any major issues. For example, if you use certain terms like “Free” or “Guaranteed,” these carry with them special legal obligations and disclosure requirements. You also want your terms of use and privacy policy to be legally binding on your site users, so it is worthwhile to have an attorney eyeball the process or flow by which these documents are presented to and accepted by users.

To give yourself a reasonable degree of comfort, ask your attorney to spend an hour (but no more) clicking through the test site, and then see what he or she comes back with.

No doubt this quick checklist will provoke howls of outrage from some business lawyers who will note scores of issues that I have either glossed over (business structure and governance issues) or omitted entirely (patents, vesting of equity for partners who make service contributions). They are correct — this is not a comprehensive blueprint for launching a new business. If you have the legal budget for that, please give me a call. Please. My point is that if you’re just a small entrepreneur without angel investors or a powerful VC sugar daddy behind you and and you only have a couple of thousand dollars or less to spend on a lawyer, you need to know where you can get the most legal bang for your buck now, and what you can defer for a few months until the business starts to generate revenue.

Which is why I’ve discussed copyrights and trademarks (which are relatively cheap and are also easy for a web business to infringe unknowingly) but not patents (which, now that the golden age of business method patents is definitely over, are less relevant to ordinary web businesses; if you feel you’ve invented something really novel and useful, definitely raise the patenting issue with your attorney, but know that it can cost tens of thousands of dollars in legal and filing fees to apply for a patent, and, in any case, you have up to a year from your first public disclosure or commercialization of the invention to file your patent application). I could give you other examples, but you get the picture.

One additional disclaimer (of course, we love disclaimers!): the figures and ranges I have given above for attorney fees represent my opinion of what these various services should cost, not necessarily what an actual firm will charge you. They are ballpark estimates to help you decide what services are most important to you and fit within your budget. Hopefully they will also facilitate a fruitful conversation with your attorney about managing costs. If you do not have this conversation at the outset, do not be surprised if you do end up getting charged a lot more.

Consulting a good business and e-commerce lawyer is a necessary part of launching a web business. Like any other professional, we have a suite of services we want to sell you. All are useful, but they need to be prioritized. A good business lawyer will do this for you, but sometimes you have to ask.

Your IT vendors laughing at the contract you signed

Hours of Support

Standard support hours in most IT support contracts are 8:30 am to 5:30 pm Monday through Friday, excluding national holidays. The first question to think about is whether you want to require 24 x 7 x 365 support coverage. Of course, the vendor will tell you it costs more, but consider pushing them on this point. If a critical system malfunction happens at 5:31 pm on Friday, and Monday is Christmas, according to the standard contract language they won’t even take your call, much less task resources to start working on the problem, until 8:30 am on Tuesday. In the meantime, you may be unable to process transactions, and/or key web functionality may be offline.

Even if you decide that the ability to call for support outside of normal business hours is not necessary, make sure that the hours of coverage listed in the contract correspond to the time zone where you are located. If your business is in Philadelphia and the coverage period is given in Pacific time, then you will essentially have three unsupported hours each morning. Also, if a “critical” bug or outage (which should be defined in the contract as one affecting a critical function of the application or equipment or one that results in a substantial inability of the application or equipment to perform the tasks it was designed for) is reported during normal business hours, the vendor should be required to work “continuously,” notwithstanding the regular coverage period, to deliver a correction or suitable workaround as soon as possible. (In other words, they can’t stop work at 5:30 on Friday and pick up again the following week.)

Standard of Diligence and Response Times

Most initial drafts of IT support contracts (i.e., vendor’s standard forms) have wishy-washy language stating that the vendor will “respond” to bug or outage reports and “attempt to fix” the reported problems. Sometimes you may see language assuring that the vendor will use “commercially reasonable efforts” to resolve issues — a favorite lawyer’s trope because no one really knows what this means and, therefore, it’s difficult or impossible to prove in court that the vendor did not use “commercially reasonable efforts.”

If you are purchasing support, you should make sure that bugs or outages are classified by levels of severity and that, at a minimum, the vendor is required to use “continuous best efforts” to correct these problems or provide suitable workarounds, either as soon as possible or within some specific timeframe that is acceptable in view of the impact the problem is likely to have on your business operations. “Continuous best efforts” is another lawyer’s term of art, but is understood to impose a very high standard of responsiveness. To use “continuous best efforts,” a vendor must work tirelessly around the clock and devote the full resources of its business to solving the problem, which, of course, is what you want.

In addition to requiring a high standard of diligence from the vendor, it is also desirable to negotiate specific requirements for initial response to a support request and regular follow-ups. For example, you might require a vendor to respond to an initial notification of a critical bug or outage within two or four hours and provide status updates every four or six hours until the problem is resolved or its severity level can be downgraded. You might also require the vendor to propose a workaround and remediation plan (i.e., a plan for restoring functionality, including projected timeframes) within a certain time after initial notification. The exact time requirements will vary as a function of the operational impact a serious bug or outage is likely to have.

Escalation Procedures

You should consider adding a procedure to the support contract by which, if a certain amount of time passes without a critical problem being fixed, the problem will be escalated up through successive levels of technical support and product engineering all the way to senior management, with a Vice President or Senior Vice President responsible for product engineering or customer service eventually taking charge of the situation. There is no motivator like the threat of the big boss getting involved if the worker bees can’t keep the customer happy.

Remedies

What happens if a critical bug or outage remains unresolved after an unacceptably long period of time? Your business is bleeding, and all too often the contract may not require the vendor to provide any remedy other than continuing to plug away at the problem. This is particularly likely to be true where the warranty period for the application or equipment has expired. Therefore, if possible, try to include a liquidated damages clause or a partial refund of the product and support costs if the product under support cannot be fixed within the time period that your business needs. The vendor’s counsel will often resist this approach because it introduces a contingent liability or a contingency that may prevent the vendor from recognizing revenue. Ultimately, it is a question of risk allocation — who should bear the loss if the product fails outside of the warranty period, but during the period for which the customer has purchased support.

Some Support Traps

When purchasing an important IT system, make sure that the support contract guarantees the availability of support for at least several years after purchase (many support contracts contain tautological language stating that support can be purchased under the contract as long as the vendor has not discontinued support for the applicable line of products, or something like this). Also, where a cap on annual support fee increases has been negotiated, make sure that the contract does not give the vendor the ability to terminate without cause at the end of each support year. (Otherwise, the vendor could use this termination right as leverage to negotiate away the cap on fee increases. Sneaky, but it happens.)

It’s Always Five O’Clock Somewhere

Support contracts often are not as carefully reviewed and negotiated as the IT licenses or product purchase agreements they accompany. However, a strong support contract is a vital component of operational risk mitigation, and if you’re paying for it, you should have some comfort that your vendor will not be at a happy hour at the most vulnerable moment for your business.

CAVEAT: When I’m representing vendors, expect me to push back on a lot of this stuff.