What's the best way to structure software contracts for small projects?

your question is pretty broad, and I'm not sure what specifically you're referring to, or whether you're the developer or the client, but as a business law attorney, here are my thoughts. Ignore me (or reply and clarify your question!) if I'm way off base here:

1. Have a master services agreement, with statement of work addenda as exhibits;
2. Pay some up front, but structure payments over time according to deliverables;
3. Make sure you have strong "work for hire" language to protect your IP;
4. Strongly consider a software escrow agreement to escrow the source code in case the company goes out of business;
5. Make sure you have strong nondisclosure language.

Hope this is helpful.

Traci D. Ellis

Incentives: Cash or equity are your options. If you pay cash, use a Software Development Agreement to set out software requirements, ownership and use of (a) developed software; (b) your right to use/own any intangibles used in the development of software contracted to be developed; and (c) any future enhancements, functionality or customization of the developed software, and the terms and conditions for payment including milestones in case the project is only partially completed for any reason. If you are offering equity in either the company or royalties on licensing of the developed software, include specific information about any updates, new functionality or customization that may not be developed by the original contractor.

Work flow process: Use a detailed statement of work with milestones. Make sure you have the names of the individuals who will be responsible for managing from the company's side or you may have issues with the contractor arguing that they did not meet milestones because of delay, unresponsiveness or misinterpreted instructions from the company.

If you are using someone else's contracts, have an attorney review it before you sign. There are any number of pitfalls that could snarl an arrangement because of the initial failure to set out expectations.

Key issues are development timing for deliverables and milestones; ownership of the ideas, methodologies, know-how and code (a) brought to the table by the developer; (b) disclosed by the entity hiring the contractor; (c) developed under the contract; and (d) any future changes to the developed software.

If you have small projects then you should have a good idea as to what the application should not only do, but how it should function.

So, start with writing out clearly what the application should do, mainly from the user POV. So, if there are five functions that the application should do, spell out clearly what should happen when things go well, and what should happen if the user does something incorrectly.

Then, just work out a schedule so you pay as functionality is done. In my hypothetical example above, have 5 places where you pay, so, when each is done, and it passes your test, then they get paid.

The incentive is that if they finish quickly they get paid the full amount without having to bill the hours you expected it to take.

How much time for each part will be a discussion, they should be able to give a reasonable explanation as to how they estimate the time.

If it is a small company, to help with bug costs, see if you can just pay them 20% maintenance after the first year, for free bug fixes, so that you don't have to have new people continue to work on it, and it will help them to have an incentive to not have bugs as they can get extra money for not having to do much. This is probably going to be a harder thing to see as a good idea, but in the long run it may be cheaper, if the application is important, so you don't have to worry about paying someone to come in and fix a program that they haven't seen.

I'm going to assume you are the developer (but this is equally applicable to the client). The fundamental piece of advice I would give is: avoid fixed-price development contracts, if at all possible. The reason is that nobody wins, unless the client has an amazing clear idea of what they want and you are unbelievably good at estimating. What happens in practice is that you always under-estimate the time and therefore the cost, and one of the parties has to pick that overrun up, causing at best ill will and worst undue financial pressure.

Instead, I would learn from the agile movement - Chapter 9 of Tom & Mary Poppendieck's excellent book Implementing Lean Software Development: From Concept to Cash has a very useful insights on contracts that gets you thinking about taking a more partnership-oriented approach, and suggests ways to drive down the risks for both parties.

Of course, all the above comments on sound legal practice apply too. But the thing about contracts is that they should be your last resort when relationships start to break down, so establishing a sound basis for your relationship with the client up-front is just as important. Whilst that may eventually be expressed in a contract, some time spent prior to starting, working through your 'working principles' will pay enormous dividends throught the project.

One final thing. Having said all this about 'agile' contracts, when dealing with larger companies, you may not get much choice - they often have their own framework agreements they expect their suppliers to sign. For this reason, don't spend any money with your lawyers until you need to, e.g. to prepare your own standard agreement. (I speak from costly personal experience.) In this case, just proceed with extreme caution :).

Hope this helps.

Thanks guys, as a development co this info is useful on both the buy and sell sides. Like all good advice, your answers have opened up new questions.

Traci, do you have an example of a solid contract to sign with clients?