Custom Software Development

Having custom-made or modified software created for your company requires that you negotiate an agreement that deals with a whole slew of issues. With custom software, you should never consider accepting the vendor's "standard form." They're inevitably one-sided in favor of your vendor. Trust me when I say this because I write those one-sided agreements.

Dealing with custom software is not like buying off-the-shelf software at the computer store. There, you're typically dealing with a non-negotiable license agreement that appears during the installation process. Agree to it and you get to finish the installation. Say no and you get a refund.

Things get much more complicated in the custom software world. Here, the typical corporate buyer may have a stronger position from which to negotiate but still be at a tremendous disadvantage due to lack of experience with these types of agreements. My goal with this (and a subsequent) article is to give you a feel for some of the issues that you should consider.

Software Licensing

Even when you "buy" custom software, the most typical transaction has the "buyer" getting a license to use the software rather than the customer buying all of the rights to the product. True purchases of software raise their own unique issues. This column will deal with the more typical license situation.

A "license" is simply a grant of a right to do something that you would not have the right to do without that license. With a software license, the single most important issue is defining the precise scope of the license. Your license must clearly state whether it's exclusive or non-exclusive, who in your organization can use it, and whether there are any limits on the location of its use.

The key here is that you must accurately project your needs for the software. You must ensure that your license permits your anticipated uses and you should have a structure in place if your needs grow. A mistake here can be costly because you will have less negotiating power down the road.

If you're going to license 150 users and six locations, just be sure to deal with the pricing of additional users and locations now. Once you're committed to your software, you don't have much choice if your software developer's pricing proposals are exorbitant for more users or locations.

You must also carefully define permitted users. If subsidiaries, independent contractors or others will need to work with the software, then get that into the license.

Software Transition

Here is one tip from the trenches. I've seen this next part omitted many times and it creates problems.

Always be sure to anticipate the process that you'll inevitably go through when you move onto a different software product way down the road. What I'm suggesting is that your custom software development agreement and license should deal with its end process. For example, you want to be sure that nothing restricts your ability to convert data to a new format.

Conceivably, transitioning to a new product may mean that you'll need to give your developer's present or future competitor access to your data and software to assist you in a transition. This may violate user, trade secret and other restrictions in your license. This is a touchy and difficult area and one where many licenses are silent. No single perfect solution exists, but still you must address this thorny issue. Nothing is forever.

Modifications

Today's innovative software is next year's antique. You must never invest in software development without thoroughly exploring updates, modifications and fixes. This is not next year's issue. This is an important part of your initial contract.

Will your developer be marketing this or similar software to others? Will the developer have an ongoing program for updates and improvements?

If you're dealing with true custom-created software, you'll probably have to fund all future development. If that's the case, you should have some pricing parameters in your agreement. Leave this until later and the price will be higher. After all, you may have no alternative than to let this developer do the work.

If you're paying for custom-modifications to preexisting software, the developer may have enough of a market for updates that it will fund the further development of the software. Then, you need to obligate the developer to license the update to you. The price might be based on a "most-favored customer" price (the best price offered to anyone) or some other arrangement.

A problem your development and license agreement must also anticipate is how to deal with custom modifications to an earlier version of the software. The problem is that your modifications may not just drop into the new version. In fact, they may not work there at all. If that happens, you may have to redevelop your modifications. This isn't so bad if you, at least, have a choice to stay with the earlier version of the software. The scenario that you must anticipate is when the developer's support obligation is contingent on you always using the latest version of the software.

I've seen an agreement where this problem wasn't anticipated. The client came to me looking for a solution to the endless cycle of updates to an off-the-shelf product that they paid the developer to modify for them. The updates were admittedly useful, but the client continued to have to pay for the custom work of adding its custom modifications to the new versions. In that particular case, the compromise solution was that the vendor agreed to support the old version at a higher than normal price. My client lost the benefit of future updates, but no longer had to pay exorbitant fees for recurring custom software development.

Software Definition

From the lawyer's perspective, probably the single most difficult part of custom software development is defining what the software should do. It's much like a construction contract for a building that hasn't even been designed yet. You don't know what its going to look like and yet you're contracting for its creation.

What features will the software have? How will it accomplish its required tasks? What will its interface look like? These are just a few of the questions that need to be answered.

One effective way to address these issues is to send perspective vendors a Request for Proposal (RFP). This gives you a chance to pick the brains of several vendors. Then, you can also take their response to the RFP and turn it into contract language. The vendors may not like that, but it's their own words.

You can anticipate a tug-of-war between the customer who wants to phrase the contract in terms of what it needs done and the vendor who wants the contract to refer to published specifications. Either way, detail is the key for the customer. You must do everything possible to insure that the vendor knows what you need and can deliver it.

One technique that I use is that I'll ask my client to give me a list of the absolute must-have features. I'll then give extra attention to those points. While it may be impossible to delineate everything that a yet-to-be-developed product will do, your computer lawyer should concentrate on those key features.

An additional article will follow later on with a discussion of other important issues in custom software contracting.

I would like to acknowledge the research assistance provided by Adam Feinsilver.