WEBSITE DEVELOPMENT PROJECTS: AVOIDING THE PITFALLS Introduction
Most organisations and companies now recognise the importance of both a web site and an effective e-commerce strategy as part of their overall marketing plans. Web site development is an integral part of the “goldrush” approach amongst many companies to get on the web. Indeed, Computer Weekly recently reported that this rush towards e-commerce has resulted in situations in larger organisations where employees working on one e-commerce project are completely unaware of similar projects being undertaken by other departments in the same organisation. This points to the fact that e-commerce and web site development projects seem to be by-passing the usual internal controls that even large organisations apply to the procurement of services from third parties.
Unless an organisation has its own resources to develop a web site, the commissioning of a web site will involve procuring the services of a specialist web site development company. However, in the whirl of technological and marketing activity, it is easy to lose sight of the need to negotiate and sign a web site development agreement that properly sets out the rights and obligations of both client and developer.
Website development projects essentially involve a partnership between client and developer, where tensions can easily arise and where both sides need to work with each other in order to achieve successful completion of the project. Such projects can range from the very minor (e.g. small web sites that act as no more than a product brochure) to complex web sites that undertake direct selling of products and services and represent the core “clicks and mortar” business of the client. Projects need to be properly managed by both client and developer - a well drafted web site development agreement provides a useful management tool in achieving this.
In many ways a web site development agreement is similar to a software development agreement and many of the issues raised in this booklet will be familiar to anyone who has previously been involved in negotiating that type of agreement. This booklet examines the most important aspects of web site development agreements and the key legal issues that arise.
“Heads of Agreement”
The speed at which e-commerce is developing instils a sense of urgency in both client and developer to get a web site project underway. This can result in web site projects commencing either without a contract at all or with a loosely drafted “letter of intent”, “letter of agreement”, “heads of agreement” or “memorandum of understanding”. From the client’s viewpoint, commencing on this basis means a significant loss of leverage when it comes to negotiate the agreement, and consequently it usually takes longer to get to a signed agreement. The developer usually argues that the letter of intent provides a guarantee of progress, that the client cannot afford delay and that heads of agreement can be non-binding to allow negotiation of key issues.
However, it is dangerous to start without a contract from the viewpoint of both client and developer. When scoping a project and the time it will take to develop a web site, clients should budget for time that needs to be spent negotiating the contract.
Obviously, there will be situations where time is limited and commercial circumstances dictate that a project needs to commence immediately on the basis of heads of agreement. In such cases, heads of agreement should be carefully managed so that they are “fair” and stated to be non-binding. In addition, the client should have a clear understanding of the
limitations which such heads of agreement may impose on its subsequent ability to negotiate a formal contract.
Website Development Agreements
The main elements of a web site development agreement (“agreement”) focus on: • Services to be provided
• Project Management • Change Control
• Approval and Acceptance • Charges and Payment • Intellectual Property Rights • Employees • Warranties • Post-Acceptance Modifications • Limitation of Liability • Source code/escrow • Termination
• Confidentiality and exclusivity • Boilerplate
• Additional Services Services to be provided
The client will want to ensure that the agreement clearly sets out the services to be provided by the developer. Most commonly this is arrived at by the client issuing a brief as to the type of web site it requires and the developer responding to that brief by providing the client with a specification - this specification should be incorporated as part of the agreement. From the client’s viewpoint, it is imperative that time is taken to define its requirements and that these are clearly set out in both the brief and eventual specification. This can then be used as a benchmark to continually refer back to during the development process. Website developers do want clients to be clear about their objectives - if not, it can be hard to tell that the project is going wrong until it’s too late.
Developers should not be permitted to get away with presenting terms and conditions with very little reference to their own obligations and the services they are to provide. Note that these services may not only include the design and development of the site but also associated services such as maintenance of the site, modifications, assistance in obtaining a domain name and web hosting services (see section on Additional Services below).
A key issue for the client will be to ensure that the services are provided on-time and that the site is developed in accordance with a project schedule. A client should therefore seek to tie the designer into a timetable that is appended to the agreement and should be careful to avoid “estimated” target dates. However, there must be some recognition on the client’s part that the developer cannot work in isolation - the developer relies on input from the client, such as the client’s employees responding to questions raised by the developer and providing materials and graphics in a timely manner. The most a developer will ever give is likely to be a best endeavours obligation to complete the project on schedule. However, depending on the negotiating strength of the developer, this is more commonly watered down to a good faith or reasonable endeavours obligation, probably with an additional express exclusion of liability where delay is caused by the client’s failure to provide reasonable assistance.
Project Management
Commercially, it is important that the project has sufficient support from persons of appropriate authority within both the client and developer. This will facilitate quick decision making and the provision of appropriate resources to the project.
Proper management of a web site development project by both client and developer is essential to its success. The agreement should therefore set out how the project will be managed and the names of the particular project managers at both client and developer. If the client is relying on the expertise of a specific individual at the developer, it may wish to provide that the individual concerned will not be replaced as the developer’s project manager without the prior written consent of the client. The regularity with which progress meetings are to be held between developer and client should be specified in the project plan which should be incorporated as a schedule to the agreement.
Change Control
Like the development of software, the development of a web site is quite likely to be subject to modification during the course of the project. To avoid delays, unnecessary extra cost and tension between the parties, it is therefore essential that the agreement includes a change control provision which clearly sets out a process for agreeing changes.
This should not only specify the process for requesting changes (e.g. the submission of a written request setting out the proposed modification) but also the scope of the changes that are to be permitted so as to avoid a fundamental change in the project as a whole (i.e. to avoid “scope creep”). Changes must be clearly specified, accurately costed and formally authorised by the appropriate persons of both the client and the developer who are responsible for managing the project. The project plan or schedule should subsequently be amended to take into account any impact on timing.
Many designers may argue that responding to change-requests is time consuming and that they should receive payment for time incurred investigating the change. However, this should be avoidable if the agreement contains a change control mechanism that requires the parties to follow an agreed process within specified parameters.
Approval and Acceptance
Approval involves approval by the client of material that is to be made available on the site -this should generally be subject to an agreed procedure. If the client’s brand or trade names are to be included on the site, the client should consider imposing an obligation on the developer that it will only include them in accordance with the instructions of the client. Acceptance of a web site involves more than testing it to ensure that it conforms its functional specification. It also involves the more subjective test of acceptance of the “look and feel” of the site.
Acceptance is likely to involve a number of stages. These will commonly comprise delivery of an Alpha version that is tested by the client at the developer’s facilities, following which the client will indicate acceptance or suggest modifications. This should be subject to key delivery dates to review various elements of the build, following which a Beta version is then produced, again for testing by the client. This is usually accessible to the client by means of a username and password which enables remote testing by the client. Once this is finally accepted, the developer should be under an obligation to deliver the completed web site to the client (“the deliverable”).
The key issue on acceptance is to ensure that a clear timetable and process is agreed and documented in the agreement. From the client’s viewpoint, this should give the client a sufficiently long testing period - in a larger organisation the client may, for example, wish to first test the site amongst its employees. The developer will have a vested interest in ensuring that the client sticks to the agreed timetable for acceptance and promptly notifies the developer of any issues or problems - payment of a proportion of the developer’s fee may be subject to final acceptance.
Charges and Payment
The fees for the development of the site itself are usually payable in stages. As such, clients should consider structuring payment terms in stages against satisfactory performance. This involves seeking “payment against delivery” - where the term delivery means satisfactory acceptance of the web site, not merely delivery of the web site on disc or on-line. Essentially, this means back loading payment so that the bulk of it is payable on acceptance. The developer will, however, wish to ensure that it has a substantial proportion of the development fee up front (around 50%). It will not wish to undertake substantial work, particularly if the client has little experience in developing web sites, without first receiving some form of payment. In addition, the developer may (depending on its expertise) be able to command an hourly rate for time incurred in preparing initial specification sheets, particularly if it involves utilising the developer’s creativity or specific expertise.
The client therefore needs to consider whether delayed payment may in fact affect the “return on investment” profile of the developer to such an extent that the developer is more likely to devote time to projects for other clients - the client should understand that the developer needs to make a profit (though not a “super profit”).
If the developer is likely to incur out of pocket expenses, the agreement should specify the level of expenditure that requires prior approval from the client. Reimbursement of those expenses should be subject to the client producing appropriate evidence of expenditure. Intellectual Property Rights
Ownership of intellectual property rights can often be a contentious issue between developer and client. From the client’s viewpoint, the client has paid for the site so feels it should own all intellectual property rights in the site. From the developer’s viewpoint, payment is not necessarily viewed as granting ownership.
The consequence of the above is that whatever is agreed must be clearly documented in the agreement. Alternatives
include:-• the developer owns the code and graphics it creates, but the client is granted ownership of graphics and data it supplies;
• the client is granted ownership of the entire web site, including all code and graphics; • the client is granted ownership of code and graphics specifically created for that client,
but the developer retains ownership of pre-existing code and graphics;
• the developer owns the entire web site, but grants to the client a non-exclusive or exclusive license to use the web site for a perpetual or defined term.
The preferred option will clearly depend on the particular circumstances of each case. From experience, the third option above is often the preferred route as it gives to the client ownership of distinctive material, code etc that has been specifically created for that client in
retains its “toolset” of existing code and graphics that give the developer a competitive advantage in the web site development market place.
A developer will be keen to ensure that any provisions regarding intellectual property rights do not restrict the developer from taking credit for designing the site. This may involve granting the developer the right to include a credit on the site itself or the right to use the site for advertising and marketing purposes such as entering the site for industry recognised awards. A client should consider whether it wishes to be associated with the developer in this way - the client should consider requiring the developer to first obtain the client’s consent prior to using the web site for such advertising purposes.
Employees
Development of a web site often involves employees of the developer building up a close relationship with the client and spending considerable amounts of time at the client’s premises. In view of the considerable expertise that may be held by certain of the developer’s employees and their consequent value to the developer, the developer should seek to prevent the client from poaching these employees and taking the project in-house by including an appropriate non-solicitation clause in the agreement.
The client should ensure that the agreement obliges the developer to provide employees who are suitably trained to provide the services and that any employee of the developer working on the client’s premises complies with all relevant site rules. Since developers often use sub-contractors rather than employees, the agreement should also make it clear that the developer is responsible for the payment of all the fees, charges and wages of its employees and subcontractors.
As with any commercial services agreement of this type, employees of the developer may end up devoting their entire time to working on the particular web site development project for the client. There is an argument that this could result in such employees automatically transferring to the client by operation of law under the Transfer of Undertakings (Protection of Employment) Regulations 1981. The client should therefore specify in the agreement that it is not intended that on termination of the agreement any employee of the developer will transfer to the client, and the client should seek an indemnity from the developer should such an employee be automatically transferred.
Warranties
Any web site development agreement should, if properly drafted, provide the client with assurances in the form of warranties as to the development of the site. These should include the
following:-• that the developer is the sole creator of the site and that the site will not infringe a third party’s intellectual property rights (excepted from this warranty should be materials provided by the client);
• that the site will be designed with the reasonable skill and care and in accordance with good industry practices. This may include an assurance that the web site will function with all the usual browsers such as Netscape and Internet Explorer;
• that the site conforms to its specification and that any software provided or used in connection with the site will function correctly and will be materially free from bugs and errors - this is likely to be limited to a warranty period (see below).
The client will seek to provide that these warranties are additional to those implied by law (e.g. warranties as to satisfactory quality and fitness for purpose). The developer will wish to specifically exclude such implied warranties and further reduce the scope of the warranties suggested above.
A warranty period may be offered by the developer to rectify any bugs or problems that cause the site to fail to continue to function in accordance with the specification. The developer will usually seek to limit such a warranty period to a period of 2 to 3 months after acceptance, although in the case of larger or more valuable projects a longer period may be offered. This should require the client to follow a set procedure for notifying a warranty claim (e.g. that issues must be notified promptly to the developer and that such notice must set out in reasonable detail the nature of the problem). Provided such procedure is complied with, the developer should normally be expected to rectify the problem free of charge.
Post-Acceptance Modifications
Aside from issues or bugs that cause the web site to fail to conform to its specification during the warranty period, modifications may be required by the client after acceptance for two other
reasons:-• the web site fails to conform to its specification after expiry of the warranty period; • the client itself wants to update or alter the functionality or design of the site.
The agreement should set out a procedure for requesting such modifications. The developer may wish to include a time limit on its obligation to make such modifications -employee turnover can be high, so -employees who have knowledge about the particular web site may quickly move on to another company.
As regards fees, where work is required to enable the web site to conform to its specification, the agreement should set out the number of hours of development time that the developer is prepared to offer at no additional cost and the cost of additional time beyond that. Where the client itself wants to update the site (e.g. make it more attractive to its customers) modifications may range from being very complex to minor. In either case, the agreement should clearly set out the developer’s cost of development time in undertaking such modifications.
Limitation of Liability
As with a software development agreement, there is commonly some jockeying for position between client and developer over the issue of limitation of liability in a development agreement.
Limitations of liability sought by the developer are likely to include the following:-• an exclusion of liability for indirect or consequential damages;
• an exclusion of all warranties implied by law (see above);
• an exclusion of liability for delays or defaults not caused by the developer, such as circumstances of force majeure or delays caused by the client’s failure to provide reasonable assistance;
• an overall limitation of liability for direct losses, usually capped at the fee paid by the client for the development of the site.
potential liability by way of insurance. The client should consider changing any overall cap on liability to include not only the fee paid for the development of the site but all other payments of any nature (e.g. maintenance fees) made in respect of the agreement. The client should also consider whether there is any element of consequential loss (e.g. loss of data) that should be included within the scope of liability.
A linked issue here is the “entire agreement clause” which will be contained in the boilerplate section of the agreement and which will generally exclude liability for any item not covered in the written contract. If there are any other issues or advice concerning the project where the client is relying on the developer but which are not covered in the agreement, the client should ensure they are specified clearly in the agreement.
Source code/escrow
The development of a web site essentially involves the development of software code. Such code may be pre-existing code that has previously been written by or for the developer or may be code that is specifically written for the web site concerned.
If ownership of the intellectual property rights in any code underlying the site is to remain with the developer, the client should seek to ensure that such code is placed in escrow with a suitable third party escrow agent (unless the client is happy that the risk of the developer’s insolvency or failure in performance is negligible). If so, the following should be borne in mind by the
client:-• updating the escrow - even if the agreement requires the developer to update the escrow, the client should take practical steps to ensure that this is being done. For example, the agreement should require the developer, at the same time as updating or modifying the web site, to provide the client with a receipt from the escrow agent confirming that the code for the update or modification has been deposited.
• events triggering the escrow - escrow agreements commonly limit these to the insolvency or cessation of business of the developer. The client should consider extending these - e.g. where the developer is in breach of contract and the client wishes to take the development in-house or appoint an alternative developer.
Termination
Developers and clients generally go into web site development projects with the idea that they are working as partners - at the time they enter into the agreement they may get on so well that termination is not even contemplated.
Inevitably, there are situations where for a variety of reasons web site development projects are terminated before they reach their conclusion. It is therefore important to set out in the agreement the circumstances in which it may be terminated and the consequences of that termination. Issues to be covered include the
following:-• termination for convenience - a number of web site development agreements allow either developer or client to terminate for convenience - for example, on 30-60 days notice. If such termination is permitted, careful consideration needs to be give to the cost implications. If client terminates, the developer will have invested much
development time in respect of which it will expect payment. If developer terminates, the client will have wasted resources on progressing the project with that developer and will have the additional cost of migrating the project to an alternative developer. In these circumstances the parties should give serious consideration to agreeing the cost of such a break option up front - this is an approach commonly taken in software
• termination for cause - the usual provisions permitting either party to terminate if the other commits a breach of the agreement or enters insolvency should be included. Consider whether there are any other causes that might justify termination.
• consequences of termination - this is a key issue for both developer and client to focus on.
From the client’s viewpoint, important issues to consider on termination include:-• the return to the client of any property that has been provided to the developer; • the delivery to the client of any materials or code that is necessary for the
continuing use of the site;
• reasonable assistance from the developer in transferring the site to any new server or service provider;
• refund of any advance payments for services not yet supplied;
• assignment of any contractual arrangements relating to the site that the developer has with third parties;
• a continuing right to use the site following termination - primarily such parts of the site where the intellectual property rights are owned by the developer.
From the developer’s viewpoint, particular concerns arising from termination include:-• the need to recover all accrued charges and due and owing by the client;
• if the site is hosted on the developer’s server, the survival following termination of any indemnities that the developer has obtained from the client, e.g. as to ownership of client’s trademark that is incorporated in its domain name.
The inclusion of the above rights will vary from agreement to agreement - in many cases, they will only apply in limited termination scenarios, e.g. where one party is in breach of the agreement.
Confidentiality and Exclusivity
During the course of a web site project both client and developer are likely to learn a great deal about each other’s business. Standard confidentiality provisions should therefore be included in the agreement preventing unauthorised disclosure or use of the other party’s information. These should continue for a defined period following termination.
In addition, the acquisition of knowledge about each other’s business may enable a party to enter the other’s industry. The more likely scenario is that the client will be concerned to prevent the developer from designing similar sites for the client’s competitors. However, the developer may also be concerned to prevent the client from using the expertise it acquires from the developer to itself design web sites for third parties. In either case, appropriate protection should be built into the agreement by way of an exclusivity or non-compete clause. This should obviously be drafted in a manner which ensures that it complies with relevant competition laws.
Boilerplate
In addition to the main issues identified above, the usual set of boilerplate clauses should be included in the agreement. Particular issues to consider
include:-• Governing law and dispute resolution - Consideration should be given to alternative means of dispute resolution other than the courts. The developer may be particularly keen to keep disputes private and avoid its name (and therefore goodwill) being dragged though litigation in the courts. Again, alternative dispute resolution is a common option in software development agreements. The key issue is to make clear in the agreement the procedures and rules that apply to such alternative forms of dispute resolution, e.g. the procedures as to escalation of the dispute within the client and developer, prior to reference to an independent adjudicator.
• Sub-contracting and assignment - the client may have chosen the developer because of the developer’s specific expertise or experience. If so, the client should seek a prohibition against the developer sub-contracting or assigning its obligations under the agreement. This prevents the developer from taking on too much work and delegating its duties to less talented developers, for example.
Additional Services
In addition to the development of the web site itself, a client is likely to require a host of additional services in order to operate the web site. Depending on the activities of the developer, the developer itself may be in a position to provide these additional services. This booklet does not go into such additional services in detail, but they may include the
following:-Website Hosting
If the client is unable to store the web site on its own servers, it will need to engage the services of a third party who stores web sites on its Internet servers, receives or stores commands or data transmitted by Internet users, transmits web page data to users’ Internet addresses and performs related maintenance. Particular issues to consider include the
following:-• the rates to be charged by the developer for such web hosting, usually a monthly fee linked to the amount of data transmitted from the client’s web site or linked to a level of bandwidth, with additional bandwidth subject to an additional fee;
• the allocation of a specific amount of hard disk space that may be used on the developer’s server to store the client’s web pages - additional fees will be payable for further blocks of space;
• the assistance of the developer to obtain a domain name for the client - this is likely to result in the developer requiring a warranty and indemnity from the client as to the client’s ownership of any trademark or name which it requests to be included in its domain name. A key issue for the client is to ensure that if the domain name is registered in the name of the developer, that domain name is transferred into the name of the client;
• an obligation on the developer to provide reports of hit statistics;
• warranties from the developer as regards the amount of bandwidth it will provide, the user-to-modem ratio it will maintain, the processor capacity it will operate and the obligations it will have as regards back up, maintenance, security and privacy.
Order and Payment Information Forwarding
If the client is proposing to undertake sales of goods or services from its web site, it may require assistance as regards processing of orders. Again, this may be a service which the developer is able to offer. This is likely to be provided subject to payment of a royalty or commission to the developer based on the monthly gross sales of goods or services sold
ISP Services
The developer may be in a position to offer to the client ISP services, incorporating basic Internet access and email accounts. If so, the developer will wish the client to abide by its operating policies which, for example, should require the client not to post or transmit any illegal, obscene or indecent material, and not to undertake unsolicited mass emailings (“spamming”). The client will be concerned to ensure that there are duties on the developer to maintain a consistent link with the Internet, provide a specific bandwidth, maintain an appropriate number of modems and operate a specified processor capacity.
The Value of a Good Development Agreement
A good contract is one which has forced the parties to properly consider at the outset all the potential issues, tensions and “what ifs” that are likely to arise during the course of the project. It should also allow for flexibility (within defined and agreed parameters) if the scope of the project needs to be altered during the course of the web site’s development. If these criteria are met, the agreement should provide the parties with an effective management tool in assisting them to achieve successful completion of the project.
Key indications of a successful project include:
• A clear brief followed by a well defined specification • Clear and achievable objectives
• Effective support from both client and developer
• Adherence to project plan or, if not, a quick resolution of outstanding issues
• A limited number of “open” issues arise - all issues have generally been resolved at the outset
• Regular and effective project meetings
In summary, as companies attach more and more value to their internet sales strategy, companies will increasingly appreciate the value of a web site development agreement that has cleared its proper internal controls and properly sets out the rights and obligations of both client and developer. For developers, as clients become more “web savvy” and sophisticated in their approach to these agreements, developers will increasingly need to be in a position to fully understand and argue the issues raised by such agreements.
Jennifer O’Brien, Associate, Corporate, Commercial & Finance Department
DISCLAIMER: This document is for general guidance only. All liability is excluded for actions taken or not taken in reliance on these guidelines alone. Specific advice should be obtained in each specific case. Please contact Jennifer O’Brien on 0207 556 6853 (email: jennifer-o’[email protected]) at Reed Smith Warner Cranston, Solicitors, London to review your specific circumstances.
