Web development is often done under a single contract. Both developers and customers may find it useful to build several contracts. This should not become too complex or too time-consuming. It will be useful only if it actually has a use.

Development

If the work to be done is web development, then there should be a contract for it. For the moment, we shall call this the ‘development’ contract; this will help us to distinguish it from the other contracts that we shall look at shortly. The development contract should cover the work involved in designing, developing, testing, populating and uploading a web site or one or more web pages. In many cases, much of the design work will be done by the customer, so that developer will complete the design, develop the pages, test them, get customer approval for them and upload them to the live site.

The web developer might becoming involved in entering data into a database - ‘populating’ it - and in submitting the site to search engines.

By the time the work is completed, the customer will have a working web site or pages, and the developer can get the contract signed off and receive final payment.

If the site is to conform to W3C or other standards, the contract should state where these can be found and should specify either an operable date for the contract or a version number or effective date for the W3C standards.

If the site is intended to be viewable with full functionality available with specific browsers, the contract should stipulate these browsers by name, platform, version and, if possible, build number. If the site is also intended to be viewable by other major browsers, although possibly without full functionality, then a list of these major browsers and their current platforms, versions and build numbers should also be in the contract. When the contract becomes effective - which is usually when it is signed - you should make a note of the current versions of the W3C specs and of the major browsers as a matter of record.

Maintenance

You may not need a maintenance contract. If the entire development has been done using standard web languages and formats, such as HTML, JavaScript, Perl and CSS, and is viewable in all major browsers, then the site can be expected to be more robust than ‘traditional’ programming, as the server and the client's browser will actually do most of the processing. Basically, you need less maintenance with HTML than you did with COBOL.

Maintenance contracts may be required where there is ‘traditional’ back-end processing, using data bases. These contracts will be focused on that back-end processing and can be treated as standard software maintenance contracts.

Where there is no back-end processing, we can expect web maintenance contracts to cover the developer ensuring that the web pages remain properly viewable by current browsers. These contracts would mainly cover any changes in the functions of the underlying script and code interpreters. Examples of this are changes to date formats with JavaScript 1.3 and the removal of support for the tag with Navigator 6.

If developers are expected to code according to current standard specifications, such as those released by W3C and other standards organizations, this kind of maintenance contract is probably not required.

If developers have used coding that is specific to a particular browser - and that browser's version - then a maintenance contract can be useful. It should be noted that most of this browser-specific coding - such as the use of in HTML for Internet Explorer - is done at the request of the customer. It would be rare to find a developer using such code unless the customer required it. Developers may therefore be more reluctant to agree to maintain it.

It may be worth mentioning that some developments are browser-specific. For intranets or where the site owner stipulates that visitors must use a particular browser, the developer may be expected to use browser-specific coding at the customer's request. The customer and developer should negotiate a maintenance contract that focuses on new versions of the chosen browser.

Hosting

Many developers also host sites for their customers. It is often useful to separate the development contract from the hosting contract. One reason for this is that the development contract is likely to terminate after the development is complete and the customer has accepted it and the developer has been paid. The hosting contract will be ongoing.

Another reason is that the development contract and the hosting contract can be managed separately. A customer may decide that they would rather host the site with some other host, although they want to continue the development with the current developer. The developer may decide that they want to have payment for the development made before they will continue to host the site.

However this is arranged, it is usually better to have two separate contracts for the development and hosting.

One possibility that may be useful to developers is to include in the hosting contract a statement that any payments received under the hosting contract while payment is still outstanding under the development contract will be applied to the development contract. This prevents the situation when a customer refuses payment for the development but continues to pay for the hosting; the developer would not be justified in taking down the customer's site under these circumstances. With this agreement in the contract, the payments will be applied to the development and the hosting will be in arrears as a result, so that the developer would be justified in taking down the customer's site.

There is no substitute for foresight.

The opinions expressed are solely those of David Blakey.
Copyright © 1996-2024