Contractual Work

[Jay1b]

Im undertaking a relatively simple project (150 hours work) for a local small business which i was recommended for by a friend.

I would like to write a contract to clarify exactly what is and what isnt included in the price. For example bug fixes and spelling mistakes will always be fixed free of charge. Small changes such as the addition of a field which does not require a new screen and just the addition of one field into a table will be free for a set amount of time, say 2 weeks later they spot something which was left off then i dont mind adding it in - however i dont want to be doing this 2 years later. I was thinking about a 1 month period.

With regards to payment, how should i break this down? Obviously i dont want to do all the work and get paid after its all complete incase they change their mind 1/2 through, on the other hand asking for a 10% cut upfront seems kind of pushy. What sort of break down should i be looking at?

Ive never written anything like this before and im not entirely sure what i need to include. Does anybody have an example or a template one they use, which they dont mind sharing? Alternatively has anybody got any tips on what else i should include?

Thanks
Jay.

 

[Denaes]

You want to include if the code is yours to alter & resell or if its exclusively their application.

Id ask for money up front, then at intervals as you meet goals.

Make sure they know what they want. If they never ask for something until they get the final product and its not there, theyll see that as a bug and the software wont be of any use to them. Now it wouldnt have been hard to add that feature in if they had asked, but now that youre done, this extra feature alters everything youve written. 150 hours down, 100 to go if you want to get paid.

Id say get a skeleton of what itll be and have them approve it. They can point out things youre missing, ask you how they would do something and you might end up writing down other features you didnt know about. Also if you can impliment something 10 different ways with equal ease, it makes sense to do it the way the customers are most comfortable with.

All this means communication the whole way through. Communication with the guy holding the checkbook and with people who will actually use the software.

Also define what a "Bug" is and what a "simple addition" is. What seems simple to a customer can be an hour or a weeks worth of programming. What they see as a bug (its not doing what they want) may just be the lack of a feature.

 

[Jay1b]

Thanks.

Ive just got to try to put that all into words now :S

 

[mskeel]

A quick Google search turned up some downloadable templates you might be able to use as either a template or inspiration for a contract.

I would recommend not offering to fix every bug for free. Define criteria ahead of time for "complete." Once the customer says "This is complete" you enter the maintenance phase. A nice thing to do would be to offer six months to a year of maintenance which includes things like bug fixes and spelling fixes. I usually offer the option of a maintenance package. For $XX you get said product, but for $YY more Ill do maintenance for six months or something like that.

As Denaes said, definitely define who owns the end product, what rights you retain, and who gets the source.

 

[Jay1b]

Ok, this is what i have so far. Could anyone give me any more pointers please?

Thanks