Software development contract - what to do?
Discussion
I've been asked to develop a bit of software for a company over the next couple of months.
I've agreed a daily rate and a fixed term for the software to be developed, what do I need to have in writing to ensure I have good recourse if they don't pay me? My preference was to work as a contractor for the term but they were talking about raising a purchase order against my ltd company and using that as the basis for the "contract".
I was thinking of raising an initial specification with dates and key features of the software, then a total cost (then the risk is up to me to do it in time) and a followup cost for support/new features etc. I get them to sign this off, then I start work.
Would asking for a deposit represent bad faith on my part? The company is reasonably new, although I know they are well backed. I wouldn't release any code until paid, but this will be pretty much irrelevant if I'm stuck holding some custom code that is worthless to anyone else!
Any other PHers work in a similar situation?
I've agreed a daily rate and a fixed term for the software to be developed, what do I need to have in writing to ensure I have good recourse if they don't pay me? My preference was to work as a contractor for the term but they were talking about raising a purchase order against my ltd company and using that as the basis for the "contract".
I was thinking of raising an initial specification with dates and key features of the software, then a total cost (then the risk is up to me to do it in time) and a followup cost for support/new features etc. I get them to sign this off, then I start work.
Would asking for a deposit represent bad faith on my part? The company is reasonably new, although I know they are well backed. I wouldn't release any code until paid, but this will be pretty much irrelevant if I'm stuck holding some custom code that is worthless to anyone else!
Any other PHers work in a similar situation?
We do this stuff all the time.
How you go about this: Create a project plan for the work that has stages, and deliverables at the end of each stage. Often this is quite artificial as until the whole thing is finished its useless but the discipline is good anyway. Agree stage payments for when your client aknowledges "Goods In" of the deliverables.
Write a specification that they can use to raise a Purchase Order - with agreed line items. These line items will be your deliverables.
Actually physically deliver the noted deliverables so there can be no argument. This means the software should be ON THEIR SERVER AND WORKING - even if it isn't fully functional.
Invoice the day after each delivery.
They're happy because they only pay as they SEE progress.
You're happy because you get to invoice *some* of the money *earlier* which is good for cash flow.
Depending on the firm the "contract" could simply be a "Letter of Intent" and the "Purchase Order" would be a "agreed payment schedule".
This is easily negotiable.
The other thing you can do is simply state that you bill monthly for the days you spend on the project. Keep timesheets. Bill according to them. If you do the work on their site get someone to sign the sheet each week. If you're doing it in your "office" then they'll have to trust you. You then write into your agreement the maximum number of days you can bill. Basically they then get to hold the last month's payment up until you deliver. Depending on project size this can work as well...
..its still a good idea to make interim deliveries/demos to convince them progress is good.
Hope any of the above helps.
How you go about this: Create a project plan for the work that has stages, and deliverables at the end of each stage. Often this is quite artificial as until the whole thing is finished its useless but the discipline is good anyway. Agree stage payments for when your client aknowledges "Goods In" of the deliverables.
Write a specification that they can use to raise a Purchase Order - with agreed line items. These line items will be your deliverables.
Actually physically deliver the noted deliverables so there can be no argument. This means the software should be ON THEIR SERVER AND WORKING - even if it isn't fully functional.
Invoice the day after each delivery.
They're happy because they only pay as they SEE progress.
You're happy because you get to invoice *some* of the money *earlier* which is good for cash flow.
Depending on the firm the "contract" could simply be a "Letter of Intent" and the "Purchase Order" would be a "agreed payment schedule".
This is easily negotiable.
The other thing you can do is simply state that you bill monthly for the days you spend on the project. Keep timesheets. Bill according to them. If you do the work on their site get someone to sign the sheet each week. If you're doing it in your "office" then they'll have to trust you. You then write into your agreement the maximum number of days you can bill. Basically they then get to hold the last month's payment up until you deliver. Depending on project size this can work as well...
..its still a good idea to make interim deliveries/demos to convince them progress is good.
Hope any of the above helps.
Sign off criteria! Get in writing exactly what you will deliver (functionality wise and other supporting stuff like doccumentation & what (if any) support you will provide).
It's amazing how many (large) companies forget to do this and get screwed over because the client continues to claim a product isn't finished/hasn't been completely delivered.
Also, when they start requesting changes from the agreed spec/deliverables, you get to charge for them.
Jim.
It's amazing how many (large) companies forget to do this and get screwed over because the client continues to claim a product isn't finished/hasn't been completely delivered.
Also, when they start requesting changes from the agreed spec/deliverables, you get to charge for them.
Jim.
SlidingSideways said:
Sign off criteria! Get in writing exactly what you will deliver (functionality wise and other supporting stuff like doccumentation & what (if any) support you will provide).
It's amazing how many (large) companies forget to do this and get screwed over because the client continues to claim a product isn't finished/hasn't been completely delivered.
Also, when they start requesting changes from the agreed spec/deliverables, you get to charge for them.
Jim.
It's amazing how many (large) companies forget to do this and get screwed over because the client continues to claim a product isn't finished/hasn't been completely delivered.
Also, when they start requesting changes from the agreed spec/deliverables, you get to charge for them.
Jim.
Interim invoicing with milestones (rough) is the best way to go, that way neither you nor the client are forking out lots upfront (be it work, or cash).
Software projects have a habit of taking longer, often the client can “change their mind” or add to the specification as they see the project taking shape, so be careful not to give them too many opportunities to move the goal posts without settling the cost of the work to date – or it could run on and on.
The key, as said already, is to clearly document everything your going to provide. It’s essential. What the client may think is a 5 minute little thing to add on could completely stuff up the entire design of the system... its absolutely essential to ensure they agree on the spec upfront. If they aren’t 100% sure, agree on the first few stages, give them a quote for that, build it and then agree on the next stages - just watch out for integration issues if later stages conflict with earlier ones, not the best way but often its not feasible to plan everything on day 1.
Software projects have a habit of taking longer, often the client can “change their mind” or add to the specification as they see the project taking shape, so be careful not to give them too many opportunities to move the goal posts without settling the cost of the work to date – or it could run on and on.
The key, as said already, is to clearly document everything your going to provide. It’s essential. What the client may think is a 5 minute little thing to add on could completely stuff up the entire design of the system... its absolutely essential to ensure they agree on the spec upfront. If they aren’t 100% sure, agree on the first few stages, give them a quote for that, build it and then agree on the next stages - just watch out for integration issues if later stages conflict with earlier ones, not the best way but often its not feasible to plan everything on day 1.
Edited by s a m on Thursday 21st September 22:45
Gassing Station | Business | Top of Page | What's New | My Stuff