Can anyone share me with a web development contract template?

[accent2010]

Thanks a lot in advance!

[rocknbil]

No. :-)

Seriously though, from my work as a freelancer, no is really the right answer - each proposal needs to be tailored to the project. An ecommerce proposal will be very different from a social networking or blogging proposal.

There are lots of templates out there, and there are lots of "build a killer proposal" articles out there too (most of them not very strong,) but when you fall into templating, you're doing what everyone else is doing. What you want is a proposal that stands out from the rest, that shows your expertise.

What I CAN tell you, however, is that a proposal is an agreement, a road map, an outline for exactly what we're going to do. What is blatantly absent in most prop's I'm asked to review, are the following:

Description: Who you are, what you are offering, in brief. ("Companyname offering demonstrated experience in [technologies] for the purpose of [short list]")

Client requirements: This part is almost always missing. Put down in writing what the client expects. "Remember we talked about a blog?" We might have talked about it, but it's not in the proposal. This lays down a clear understanding of what is expected of both parties. Furthermore, this is the first stronghold you will have on change of scope or project creep; define what they want in writing. The goal of this clause: "here are the problems you want to solve." If this part is incorrect, the client should sound off.

Project Framework: Detailed description of ALL tasks to be performed. Make it many pages if you need, create wireframes to graphically describe what you're doing, and most important, be specific. "Install a CMS to allow customer management of data" is vague and can be anything. Any loose ends you leave open are opportunities for it to be interpreted in any way they choose. "A Wordpress based CMS to manage basic front end pages and the blog section of the site, and [some cart] for the management of the ecommerce area of the web site" is far better.

If you're creating programming interfaces, define EXACTLY each step and page view. This is incredibly important. I had a client once ask for a proposal to create a database. He just figured searching and displaying records was automatic, he had no idea that robust programming was required to search and display his back end data, and that user's front end data required a bit of work to get into the database. Every detail, leave no stone unturned.

The goal of this section: Here is how I plan to solve the problems defined above.

Milestones: Although most proposals contain some vague description of timeline, what is often missing are milestones. Milestones can be used to demark payment intervals, but more importantly can be used as short term goals in large projects. Examples might be:

- Present static designs: 5-7 working days
- Install CMS, implement designs into CMS, rough out basic pages, 5-7 working days
- Install cart software, integrate designs into cart, add basic starter set of ten products, 1-2 weeks
- Basic training of usage not to exceed 5 billable hours
- Project complete, remain available for 30 days of basic support without change of scope of this proposal.

What did I miss in the milestones above? :-) The third one should read " . . . and configure cart to connect with the payment processor of the client's choosing." I did that on purpose . . . guess what happens if you leave it out?

"Are you $%45$%ing kidding me? What good is a shopping cart if I can't accept payments? OF COURSE that is part of the deal, do it or you don't get paid!"

Add a clause that states no work on milestones will commence until the previous milestone is approved by the client (and how much time they get to approve.) That last milestone is **real** important. On day 15, client decides "wow, I forgot, I need a forum. Can you throw that in?" The response would be sure, as a separate project. The goal of this section: Define benchmarks of progress so both parties know what to expect.

Scope Definition: Clearly define what is within and not within the scope of this project. It may include anything like color scheme changes on the fly, but anything that requires going back to step one or major revisions of previously completed milestones is considered out of the project's scope. Also state if there are requirements out of scope, indicate all progress will stop and you will provide a revised proposal. Goal of this section: Draw big red lines around the limits of what you're committing to. This is the one HUGE error most developers fail to do. Otherwise you find yourself at this point:

"You know, when we first started I wasn't sure how well you'd do, but I'm just not happy with it. I'm willing to continue working with you but we really need to start over."

Project Timeline: Different than milestones, use specific dates. "6-8 weeks total to commence on acceptance of this proposal. This proposal is valid for a period of 30 days starting from [this date]." Be sure to include a disclaimer that maintaining the project schedule is dependent on client responses to completed milestones, and outline any actions that will be taken should the client fail to meet these requirements.

Project costs: This part they usually get right. :-) State payment terms and periods, as mentioned it's often a good idea to pay by the milestone so if someone decides to ditch halfway through, everyone gets what they expect.

Definitions and legalese: Define property rights "do I own this code now?" Seems obvious, but put it in writing, and include any clauses relating to third party materials (stock photos or open source software, for example.) Define warranty, liabilities, and what you are not liable for. Define the relationship of the parties ("independent contractor, not in employ, client cannot dictate the hours, duration, or location of work"). Define what we do if either party decides to terminate the agreement. Define confidentiality - which becomes important if the client lets someone else log in, look at your code, and start a game of king of the mountain.

Other than the legalese, do not use flashy buzzwords. "Implementation of PHP, Javascript, Jquery, mySQL, and XML" may sound like you know what you're saying, but it's fluff. These are things the client won't understand, so don't use them. Speak in plain ordinary English.

HOLY CRAP that's a lot of work! Trust me, as someone who has worked for 50 cents an hour at the end of an open ended agreement, this is well worth it, and once you have the first one you can base subsequent ones off it. The other argument I see is really based out of laziness on the part of the proposal writer: the justification that the client doesn't want to read all this, they won't understand it.

Every client that's seen my proposals has awarded the projects hands down because the attention to detail really shows you know what you're doing, and they have very few questions about what I'm going to do. They just get out of the car, point to the steering wheel, and get in the passenger side. :-)

[httpwebwitch]

rocknbil that was amazing

[Leosghost]

Incredible Mr rocknbil..one for "pinning" to the "library" here .. and the wall of any developer..;-)

+ very many internets.

[albo]

Very very good. Extra points for including explicit coverage for the client saying, partway through, "we need to add [or change] such-and-such..."

I don't know how or whether to include it, but, would you make it explicit that "consulting time" is NOT free? Some of my clients have considered ALL time spent in meetings to be free of charge and separate from costs, during and after. Meetings/consultations are both essential to the project and involve a substantial element of time spent throughout.

[sundaridevi]

That was a pretty good summary of the project requirements rocknbil, but the OP asked for a contract template. You did also cover those issues a bit. It's really important to define the project requirements and scope of work, but there's a lot more that needs to go in there too. Normally the proposal comes from the developer and the contract comes from the client. the client could attach the proposal (or parts of it - e.g. milestones) as an Appendix.

In my experience, two of the key points that you need in a contract that may not be obvious to many people:

- Work for hire: The job is work for hire. Then you own everything and if the guy helps you build the next facebook, he can't come back two years later claiming he owns a % of the company. This is essential.

- Termination: whenever a job goes bad, this is the first thing you will look at. The termination clause describes under what circumstances the job can be terminated and how (monetary, time delay, who gets what, etc).

[explorador]

Great post rocknbil, a lot of things covered.

x2 sundarivei

As for contract, the crucial stuff is to define when or how the relationship could be terminated and in what terms. Most of this documents goes to clarify what are your responsibilities and of your client.

Per example:

• What's included in the price
  
• How long you can mantain the price
  
• How other stuff (and what) can increase the costs
  
• Deadlines, how and when your client should deliver the content and ideas to you in specific dates.
  
• How a delayed delivery can compromise the project depending on special dates and even to the point of making the project a bad idea for you or the client.
  
• Clarify the ownership of each stuff. Some clients claim that even the unused drafts belong to them. Make clear what will be delivered to the client and when
  
• The previos one applies even to when the project is finished, perhaps at your server, this means if the client should find someone to take out the files and migrate or if you offer this on a CD or tarball, etc.
  
• Make clear that some stuff will not depend on you (define them) and you can't go on on certain steps until that info or material is delivered to you, and that's not entirely your responsibility.

I work this way with my clients after my own mistakes, being too friendly and learning from friends and guidelines of formal companies.

Some clients hate this protocol mainly because it puts responsibility on their shoulders too, not only mine but this is the way to work. Basically with big companies this is the way in my experience, and the payment has been sometimes 20%, then 20% and the rest at the end. It might vary on your taste or the company.

In my country you can buy "fianzas" for contracts (usually the contractor is the one who pays for it). Found the traslation as "Bond", it is some sort of insurance for the job. This implies in most cases that a certain company or whatever might review the work and decide if you were loyal to the contract, then aproving the payment. It could mean differences of payment (sanctions) on quality or schedule. Is not very common but big audited companies in my country opt for it.

So discuss all these with your client, what matters at the end is what's on the contract, it will protect your client and it will protect you too.

[DirigoDev]

I agree with rocknbil. Proposals should all be custom with much thought. A mentor once told me that when you pitch a deal you should already have all the work figured out. We never put less than 10 hours and often put 80+ hours into a pitch. We usually get the job - often at a higher cost (e.g the client pays more to use us than the competition). Why? Because we come with everything spelled out as a solution to the problem. It is all black and white with no room for interpretation. I learned back in 1999 the hard way - on a 700 hour project that boiled down to a few bucks an hour. I got hurt bad.

I'll share this bit - a version of our terms which comes at the end of a 10-40 page proposal:

DEVELOPMENT TERMS

TIME FOR PAYMENT: The project will be billed in three equal payments with the first payment due within 30 days of the start date. Other payments are due in the second and third month. [Change depending on the project--clients really like the 3 payment option on smaller projects. Bigger projects are always billed monthly. No money changes hands to start the work. This is the way we roll.] All invoices are due upon receipt. XYZ Co. reserves the right to suspend performance of services and withhold delivery of materials until payment is made in full of all amounts due.

DEFAULT IN PAYMENT: The client shall assume responsibility for all collection of legal fees necessitated by default in payment.

CHARGES: The client shall be responsible for payment of any alterations requested above and beyond the original assignment that are required to facilitate completion of the assignment. The charges (i.e. change order) will be billed at the hourly rate of [x dollars] (e.g. strategy, feasibility, and direct response/database administration) and [x dollars] (e.g. creative, branding/logo, Web site design and functionality, SEO, and content development and editing). However, no additional payment shall be made for changes required to conform to the original assignment description.

XYZ Co. fees are primarily based on hours spent multiplied by our hourly rate. In addition to fees for services, XYZ., bills for disbursements that may include but is not limited to: excessive long distance/international telephone charges, extraordinary postage, filing fees, lodging, travel expenses, and legal fees. Ongoing projects are typically billed on the first day of each month for tim¬e spent in the preceding month.

ESTIMATES: Estimates will be supplied at the client’s request. Final fees and expenses will be shown when the XYZ Co. invoice is rendered. The client’s written approval shall be obtained for any increases in fees or expenses that exceed the original estimate by ten (10) percent or more. The client is to set a budget on all non-routine tasks. Where estimates are not provided the client will be billed the normal hourly rate.

SCOPE OF WORK: XYZ Co. will provide various information technology-related consulting, chiefly internet business consulting, business strategy, Web site design, and XYZ Co. proprietary systems.

INDEPENDENT CONTRACTOR STATUS: The client considers XYZ Co., an independent contractor in this engagement. XYZ Co. is not an employee or an agent of the client in any form or purpose. XYZ Co. is not authorized to bind the client in any manner.

CONFIDENTIALITY and NON-DISCLOSURE: Both parties will enter into a mutual Confidentiality and Non-Disclosure Agreement (CNDA), which is hereby incorporated into and made part of all work performed. The CNDA will survive the termination or expiration of any engagement.

WORK FOR HIRE: Unless otherwise noted in writing in advance of a project, computer programming work performed by XYZ Co. is NOT work for hire. All computer code and applications are delivered with a perpetual license giving the client unlimited use and the right to change, reuse or augment the code. XYZ Co. retains ownership of the code-base. Creative design and strategy work is the client’s exclusive property.

CANCELLATION: Upon fifteen (15) days written notice delivered by U.S. Mail, either party may cancel with or without cause. In the event of cancellation, a cancellation fee equal to work completed—based on the agreed upon price prorated to expenses already incurred—shall be paid by the client. In return, XYZ Co. will provide the client with smooth transition to its vendor of choice. XYZ Co. is bound by this agreement to assist the client in an orderly transition billed at the standard rate in the event of cancellation.

MODIFICATIONS: Modifications of the Agreement must be written and signed by the client and XYZ Co.

WARRANTY OF ORIGINALITY: XYZ Co. warrants and represents that: To the best of our knowledge, its work is original and has not been previously published, or that consent to use has been obtained through the undersigned from third parties is original or, if previously published, that unqualified consent to use has been obtained on an unlimited basis; that XYZ Co. has full authority to make this agreement; and that the work prepared by XYZ Co. does not contain scandalous, libelous, or unlawful matter. This warranty does not extend to any uses that the client or others may make of XYZ Co. product which may infringe on the rights of others. Client expressly agrees that it will hold XYZ Co. harmless for all liability caused by the client’s use of XYZ Co.’s product to the extent such use infringes on the rights of others. The client further expressly agrees that it will indemnify XYZ Co. and cover all costs and attorney’s fees for any and all liability caused by, or arising from, the client’s use of any materials provided by it and used by XYZ Co. in any authorized project.

LIMITATION OF LIABILITY: Client agrees that it shall not hold XYZ Co. liable for any incidental or consequential damages which arise from XYZ Co.’s negligent failure to perform any aspect of an assignment. The client further agrees that it shall not hold XYZ Co. liable for any incidental or consequential damages which arise from the client or a third party’s failure to perform any aspect of the assignment, regardless of whether such failure was caused by intentional or negligent acts or omissions of the client or a third party.

DISPUTE RESOLUTION: Any disputes arising out of this Agreement over five thousand ($5,000) dollars shall be submitted to binding arbitration before the Joint Ethics Committee or a mutually agreed upon arbitrator pursuant to the rules of the American Arbitration Association. The Arbitrator’s award shall be final, and judgment may be entered in any court having jurisdiction thereof. The client shall pay all arbitration and court costs, reasonable attorney’s fees, and legal interest on any award of judgment in favor of XYZ Co. For projects $5,000 or less, the client and XYZ Co. have the ability to dispute claims in Small Claims Court in the state of XYZ CO STATE OF DOMICILE.

[aspdaddy]

Have a look at the ones on the freelance websites, the legal stuff is fairly standard,
then you just add a proposal/description of work as separate document(s) - this can include text descriptions and/or prototypes of what needs to be done - the more detail the better

[aspdaddy]

rocknbil, the problem with your suggestion above is that who will pay for all this work? This is the real problem solving / planning work that is i agree essential - but needs to be done as part of the project scoping after the contract is aagreed.

[rocknbil]

If you can't calculate the overhead of comprehensive business proposals into your business operations, you probably should be doing something else for a living. It's the same thing as justifying the cost of an airbag so you can fly a 3000 lb. chunk of machinery at 70 MPH or so.

[aspdaddy]

I calculate fine in business operations, where its billable and is called scoping - rather than in pre-sales - where its not-billable and called quoting

[DirigoDev]

There are many different business models. We factor a big chunk of the scoping and problem solving into the proposal. This tactic outclasses the competition and lands the business better than 75% of the time. We build in the cost of the time into the finished proposal. If we get the work we get paid. If not, we chalk it up as G&A (just the cost of doing business). Our firm does not have or need a sales department or dedicated salespeople. The Sr. Partners pitch with the help of all the staff as we create solutions that work. We get all the work we want at a solid hourly rate – often at a higher rate than our nearest competitor. We oftentimes come in with a much higher overall price tag and still win business because everything is spelled out. Years ago we ran the shop with the mindset of @aspdaddy.

Who will pay for all this work?

The client will gladly pay.

<caveat>All that you need to do is get the deal.</caveat>

The deal is always based on a solution and a clear plan!

[sundaridevi]

The OP hasn't come back? In case they are still interested, I just ran across a "web development contract template" as requested. It's in the book, Multimedia Law and Business Handbook by Brinson and Radcliffe, 1996.

It's also worth noting that some of the discussion of contracts in the book would indicate that parts of the contract posted by DirigoDev are invalid in the United States, specifically concerning "work for hire" and "perpetual license".

I've been to court two times concerning development contracts. Once for somebody I hired and once to sue a client who violated the terms of the contract. A roll your own contract would have been worthless to me, so luckily my contracts were written by lawyers. If you want to have a contract, make sure it is worth the paper it's written on. In this discussion, there isn't even much to show that people see a difference between a contract and a proposal.

[aspdaddy]

In this discussion, there isn't even much to show that people see a difference between a contract and a proposal.

I actually made that distinction clearly in my first post. As stated already, the legals are standard business stuff, you dont need a lawyer each time you contract to build a website do you? Maybe for a very big one..and in the US where you need a lawyer each time you do anything... you dont see many cases of RAC, Elances or similar in court now do you ?

Thousands of projects worth millions all using the same standard contract, I wonder how that works...

The deal is always based on a solution and a clear plan!

Often the deal is based on your contacts with the prospect, sales skill and price.

[sundaridevi]

I always use the same contract with slight modification, but I think what is important is starting out with a solid contract that you can use for many different projects in the future.

Re: Elance, I had a project there that ended up in dispute a few years ago. The issues are:

- contractor is usually in a foreign country and even if you won a lawsuit you might never see any money
- the lawsuit might cost more than you lost on the contract

I just terminated them and cut my losses as I suppose many people do.