For very short programming jobs, how should one approach the concept of a contract?

Question

I am wondering what other contractors in the field of software development do when a potential client approaches them with a spec.. in terms of contracts. In my experience, clients will often be happy to proceed with no formal agreement. I know this is quite an open ended question, so I will break it down into a series of subquestions that can be actually answered.

If the client does not have a contract for you to sign, do you present a physical contract to them?

If you have such a contract to present to clients, how did you acquire such a thing? Obviously you can pay through the nose to have a lawyer write it, and other obvious answers, but are there other reasonable (cost effective?) solutions to acquiring such a contract?

At what stage, if any, would you require the client to physically sign such a contract? (what if the job is just one day?)

In some cases, the software you are providing to the client is a customized version of an off-the-shelf, open-source, or proprietary in-house software, how does this affect things?

I realise that the best answer is probably "It depends on the client, and other factors..", you don't need to tell me that. But what are your experiences and opinions about 'best practices' in this area? Or to put a programming slant on it, do you have a reliable algorithm for managing the contract side of things, ie keeping both sides happy, most of the time?

Answer 1

The main things you want to protect yourself from are:

1. The customer not paying you
2. The customer suing you

For a small project less then 1 weeks worth of work. protect myself by having the customer pay a 50% deposit up front. Then once complete I demo the project and get the remaining 50% before I hand over the code. This makes it quick and easy for both parties who do not want to get scared off by contracts. I think number 2 is quite rare so I do not worry about it for small projects.

For any project over 1 weeks worth of work I have the customer pay 30% up front. Sign a contract I provide myself. Have the customer pay progress payments at every 15-25% complete. The contract I have covers me for things like them not paying, scope of work to be completed, not being libable for an damages or content they provide that may be illegal etc.

The contract also provides the customer some saftey that I will deliver on time and what will happen if I do not meet the deadline etc.

I constructed a generic contract myself without a laywer which I use for all projects (I only do small project less then 2 months work). I also attach a seperate Project specific Costing and Devliverables as appendixes to the contract. They explain in detail what will and will not be in scope.

I wrote my contract by googling other contracts online and taking sections from here and there until I had one contract that suited my needs. Probably not the best solution but it works for these small simple projects.

Answer 2

You should present a contract quickly after you've come to a verbal agreement on terms. You want to clarify scope of work, payment terms, and liability, at least. You're better off presenting a contract your own attorney has drafted first, mostly because you'll start off with far more favorable terms than most companies will present you with in their boilerplate documents.

As an example, my attorney specifically called out a subvendor agreement I was reviewing as unfavorable to me because it required a more expensive form of arbitration than he recommends for smaller companies; he redlined it with an agreeable alternative. The choice of law can be a factor as well; one company wanted my contract to be subject to California law even though both of us primarily operate in Washington state. Also, be careful to minimize indemnification risks; most companies will try to sneak in a clause to their vendors that indemnifies them against all claims, sometimes subtly including you as a potential defendant in civil cases that may not even have anything to do with your own errors or omissions.

There's plenty of room for adjustments in most long-term contracts. If you have a clearly defined scope of work, you can reference that in the contract as an attachment. If it's less clear, you can specify the terms upon which you agree to work, what is required in order to allow a variance, etc.

I personally don't choose software contracts with one day timeframes, so I can't help there. But if you expect to do a lot of that kind of work, you should ask an attorney to draft a contract for you that can be quickly tailored to different scopes of work, so that you have a standard agreement for small projects. If this is a one-off project, and you don't plan to do similar work again, an attorney may cost you as much as the job pays, so you can certainly scribble something in Word that just covers payment terms, scope of work and what path you'll take in the event of a dispute or disagreement.

By the way, your question isn't really specific to programming, it's general enough to apply to all sorts of contract deliverables. "Consult your attorney" is probably the wisest answer.

Answer 3

Talk to a lawyer about a contract you can modify to suit your needs. Your contract should include an appendix detailing deliverables, scope, and liability. If a lawyer is not in your price range, look for well-reviewed, simple contract templates online.

Establish a contract with the client as early as possible. You can always agree on changes later. Request an up-front percentage (client honesty) of up to 50%. If you're being paid hourly, give an estimate (your honesty) and request a percentage of the estimate. For longer-term projects, request progress payments in exchange for progress reports (mutual honesty).