Contractual Work

J

Jay1b

Contributor
Joined
Aug 3, 2003
Messages
640
Location
Kent, Uk.
I'm 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?

I've never written anything like this before and i'm 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.
 
You want to include if the code is yours to alter & resell or if it's exclusively their application.

I'd 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 it's not there, they'll see that as a bug and the software won't be of any use to them. Now it wouldn't have been hard to add that feature in if they had asked, but now that you're done, this extra feature alters everything you've written. 150 hours down, 100 to go if you want to get paid.

I'd say get a skeleton of what it'll be and have them approve it. They can point out things you're missing, ask you how they would do something and you might end up writing down other features you didn't 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 (it's not doing what they want) may just be the lack of a feature.
 
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 I'll 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.
 
Back
Top