Contract for a freelance software project
May 13, 2011 8:45 AM Subscribe
How do I set up a contract? This is my first freelance software-development project and I have no idea what I'm doing.
I'm probably going to write a small application for an individual. I've never done this before, so I don't know how to create a contract to make sure we both get what we want. I'm sure there's a standard way of doing this, but I have no idea what it is.
Problems include:
1. How do I decide the price? Should I let the client make the first offer? I'd like to charge hourly, because I don't know how long it will take, but I assume the client will object (because he can't tell how long it really took). Either I need to prove how long it took me, or I need to come up with a lump sum for the whole project.
2. How do I make sure the requirements are clear, and that the client and I agree on them? What if he changes his mind and insists that I need to do something that I don't think I need to do?
3. How do I make sure he pays me and doesn't just disappear?
The client says he's working on a requirements document now. I don't know if he knows what he's doing—if he does, he might try to screw me over, and if he doesn't, we both need help.
If you've done this kind of thing before, please let me know how it's done! There are probably more issues I haven't thought of yet, so any advice you can offer would be greatly appreciated.
I'm probably going to write a small application for an individual. I've never done this before, so I don't know how to create a contract to make sure we both get what we want. I'm sure there's a standard way of doing this, but I have no idea what it is.
Problems include:
1. How do I decide the price? Should I let the client make the first offer? I'd like to charge hourly, because I don't know how long it will take, but I assume the client will object (because he can't tell how long it really took). Either I need to prove how long it took me, or I need to come up with a lump sum for the whole project.
2. How do I make sure the requirements are clear, and that the client and I agree on them? What if he changes his mind and insists that I need to do something that I don't think I need to do?
3. How do I make sure he pays me and doesn't just disappear?
The client says he's working on a requirements document now. I don't know if he knows what he's doing—if he does, he might try to screw me over, and if he doesn't, we both need help.
If you've done this kind of thing before, please let me know how it's done! There are probably more issues I haven't thought of yet, so any advice you can offer would be greatly appreciated.
1) Once you understand what he needs, give him an estimate based on time. So for example, this looks like 20 hours of work, and at my rate of $100/hr, that is $2000. Then describe what you are delivering as completely as you can, with a note that any changes or deviations will require a change order that you both approve, and an increase in price. Obviously, when trying to to do a fix cost bid like this, pad the original estimate a bit ( I like 25%) to cover your ass.
2) Everything in writing.
3) Get 50% up front, and the balance upon completion. If it's a longer drawn out project, 50% up front, 25% on some milestone, and the balance on completion.
posted by COD at 9:00 AM on May 13, 2011
2) Everything in writing.
3) Get 50% up front, and the balance upon completion. If it's a longer drawn out project, 50% up front, 25% on some milestone, and the balance on completion.
posted by COD at 9:00 AM on May 13, 2011
Response by poster: I'm not asking for help with the price itself (yet). What I want to know is whether to charge a fixed price or hourly. Is it generally agreed that a fixed price is the way to go?
I also have no idea what the client is expecting to pay yet, so I wonder if it's a good idea to let him make the first offer.
posted by Chicken Boolean at 9:09 AM on May 13, 2011
I also have no idea what the client is expecting to pay yet, so I wonder if it's a good idea to let him make the first offer.
posted by Chicken Boolean at 9:09 AM on May 13, 2011
First, obligatory disclaimer: I do exactly this, but on the side, not as a professional, I'm still figuring a lot of this out, and this all may be terrible advice so feel free to not listen to it. I'm not a lawyer or anyone you should take advice from. That said, here's what I've learned...
1. Don't underestimate the importance of the requirements document, because non-developers have NO idea what's hard and what's not. So yeah, your client probably doesn't "know what he's doing". He does know what he wants, but he may have no idea what you're going to need in this document so you must put it there before signing anything.
Example: I don't know exactly what area you're working in, but if you (like me) do mobile development for iPhone or what-have-you, get some detailed requirements. What does this button do, exactly? Do things whoosh around the screen when they appear? That icon... who's designing and supplying it? Your clients will be surprised (and quite possibly annoyed) by this level of detail, but it's pretty hard for you to do your job otherwise, because...
2. Be prepared for your clients to want to change things. They'll see your work and invariable say "this is great! But I just thought of something, and I'd like it to do X instead!" Not a problem, right? Be prepared for this. Some of these things will be reasonable; your (very detailed) documentation will inevitably still have some holes and misunderstandings in it, and in those cases I like to clear it up without getting into a fight about price, etc. Other requests will be larger, not in the scope of the original project, and will need further negotiation. Have an understanding from the very start that stuff like this is not included in your original quote, and while you're happy to discuss it (more work!) it's going to require rethinking the cost.
If he insists that you need to do something that you don't think you need to do... that's what the requirements document is for, so make it a good one. See above.
3. Price is the hardest one for me right now, and I don't really have a good answer. If you have to quote (and meet) a total price, then try not to screw yourself on it (as I've done repeatedly). Estimate how long it will take you... and then pad it. COD says 25%; I say double it. Seriously. First because most people (most people I know, at least) lowball the amount of time it'll take, and you'll also need time to incorporate reasonable changes. Also, if you have to learn something new to finish the project, be aware that'll likely take more time than you thought.
4. If you can work hourly, that's great; most clients won't want to, but if you can get away with it, it'll make them happier if you frequently give them detailed reports on (a) the time you've spent this week, and (b) the progress you've achieved. They care more about this if hourly. I've never managed to get anyone to agree to hourly. :-)
5. Your hourly rate really does vary, a lot. It depends on how niche the project is, how (un)common your skill set is... basically what gauche said. Letting your client make the first offer seems... bad. Clients often seem surprised by how expensive software development actually is. Let him offer first, and he'll likely offer something much smaller than you're expecting. If you want some wiggle room for negotiation, I'd pad the quote a bit first.
6. Writing contracts certainly can be done by anyone, google around for other peoples' freelancing contracts (haven't looked but I'm sure they are out there) and base yours off that. If you anticipate doing a fair amount of this, might not be a bad idea to meet with an attorney and have them give it a once over. As far as billing, etc, goes, freelance software dev isn't any different from any other profession where you're doing work for people and you want to be sure they pay you. There's scads of stuff on the internet. Go read it.
7. Everything COD and gauche said. Sorry for the lengthy comment. Good luck!
posted by captainawesome at 9:17 AM on May 13, 2011
1. Don't underestimate the importance of the requirements document, because non-developers have NO idea what's hard and what's not. So yeah, your client probably doesn't "know what he's doing". He does know what he wants, but he may have no idea what you're going to need in this document so you must put it there before signing anything.
Example: I don't know exactly what area you're working in, but if you (like me) do mobile development for iPhone or what-have-you, get some detailed requirements. What does this button do, exactly? Do things whoosh around the screen when they appear? That icon... who's designing and supplying it? Your clients will be surprised (and quite possibly annoyed) by this level of detail, but it's pretty hard for you to do your job otherwise, because...
2. Be prepared for your clients to want to change things. They'll see your work and invariable say "this is great! But I just thought of something, and I'd like it to do X instead!" Not a problem, right? Be prepared for this. Some of these things will be reasonable; your (very detailed) documentation will inevitably still have some holes and misunderstandings in it, and in those cases I like to clear it up without getting into a fight about price, etc. Other requests will be larger, not in the scope of the original project, and will need further negotiation. Have an understanding from the very start that stuff like this is not included in your original quote, and while you're happy to discuss it (more work!) it's going to require rethinking the cost.
If he insists that you need to do something that you don't think you need to do... that's what the requirements document is for, so make it a good one. See above.
3. Price is the hardest one for me right now, and I don't really have a good answer. If you have to quote (and meet) a total price, then try not to screw yourself on it (as I've done repeatedly). Estimate how long it will take you... and then pad it. COD says 25%; I say double it. Seriously. First because most people (most people I know, at least) lowball the amount of time it'll take, and you'll also need time to incorporate reasonable changes. Also, if you have to learn something new to finish the project, be aware that'll likely take more time than you thought.
4. If you can work hourly, that's great; most clients won't want to, but if you can get away with it, it'll make them happier if you frequently give them detailed reports on (a) the time you've spent this week, and (b) the progress you've achieved. They care more about this if hourly. I've never managed to get anyone to agree to hourly. :-)
5. Your hourly rate really does vary, a lot. It depends on how niche the project is, how (un)common your skill set is... basically what gauche said. Letting your client make the first offer seems... bad. Clients often seem surprised by how expensive software development actually is. Let him offer first, and he'll likely offer something much smaller than you're expecting. If you want some wiggle room for negotiation, I'd pad the quote a bit first.
6. Writing contracts certainly can be done by anyone, google around for other peoples' freelancing contracts (haven't looked but I'm sure they are out there) and base yours off that. If you anticipate doing a fair amount of this, might not be a bad idea to meet with an attorney and have them give it a once over. As far as billing, etc, goes, freelance software dev isn't any different from any other profession where you're doing work for people and you want to be sure they pay you. There's scads of stuff on the internet. Go read it.
7. Everything COD and gauche said. Sorry for the lengthy comment. Good luck!
posted by captainawesome at 9:17 AM on May 13, 2011
On hourly versus fixed price, I agree with what captainawesome is saying.
You might be able to do both though. If you haven't done a lot of freelance projects, it will be hard to find the right quote. One thing I tried with a couple clients when I started out was to give them a maximum estimate for the project and then bill at an hourly rate. So, figure how many hours it will take, multiply by an appropriate hourly rate, and generously pad it. Quote this number to your client as the maximum estimate for the project - let's say $2000. Then tell them that you will send regular updates/invoices as you put in more hours. If in the end it only adds up to $1600, well the client only has to pay $1600. This keeps you honest and it covers your ass, because that estimate is going to be high. I found that a couple clients were willing to meet my higher price when I described it this way instead of a flat, fixed price. You should also put something in your contract that says what will happen when you approach that maximum but aren't close to finishing. Something like you'll "explain why the project is taking longer than estimated, and renegotiate the rest of the project."
The same disclaimers as above apply. This worked OK for me, but it might be terrible advice for you.
posted by MrFTBN at 10:41 AM on May 13, 2011
You might be able to do both though. If you haven't done a lot of freelance projects, it will be hard to find the right quote. One thing I tried with a couple clients when I started out was to give them a maximum estimate for the project and then bill at an hourly rate. So, figure how many hours it will take, multiply by an appropriate hourly rate, and generously pad it. Quote this number to your client as the maximum estimate for the project - let's say $2000. Then tell them that you will send regular updates/invoices as you put in more hours. If in the end it only adds up to $1600, well the client only has to pay $1600. This keeps you honest and it covers your ass, because that estimate is going to be high. I found that a couple clients were willing to meet my higher price when I described it this way instead of a flat, fixed price. You should also put something in your contract that says what will happen when you approach that maximum but aren't close to finishing. Something like you'll "explain why the project is taking longer than estimated, and renegotiate the rest of the project."
The same disclaimers as above apply. This worked OK for me, but it might be terrible advice for you.
posted by MrFTBN at 10:41 AM on May 13, 2011
I've been a freelance web designer and developer for about a dozen years
1. How do I decide the price?
I never, ever, ever, ever do fixed-bid projects. I charge an hourly rate, and if the client doesn't like that, they can go hire someone else. I'll do estimates, and I'll scale the work towards a target budget when necessary, but I will not commit to a fixed bid under any circumstances.
I have never had a client balk at this. (I do have one client whose corporate management requires them to engage only in fixed-bid projects, so what we do is contract it out for an outrageous worst-possible-case-then-double-it amount, then I bill them only for the hours I actually end up working -- more or less what MrFTBN suggests above.)
The problem with fixed-bid projects is that you have to spend a tremendous amount of time up front scoping the project: figuring out what exactly will be included, how many revisions will be allowed, and so on. Projects always change while you're working on them, there are always new ideas or late additions, and if you're working on a fixed bid you either have to suck it up and do them for free or renegotiate a contract update. The incentive is for the client to squeeze in as many last minute changes as possible while they've still got you, because it's all free to them.
When you're hourly you don't have to worry about change requests: they're just more hours. Keep them informed of how much they're spending, and the incentive will be for them to draw things smoothly to a close.
Either I need to prove how long it took me
If they trust you enough to base some part of their business presence on your skills and work, they need to trust you enough to accurately report your hours. (And you need to repay that trust by in fact accurately reporting your hours.) At the end of the day either they'll feel like they got their money's worth, or they won't; that's going to be down to the quality of your work more than the number of hours.
2. How do I make sure the requirements are clear, and that the client and I agree on them?
Well, if you go hourly, this becomes almost a non-issue. I tend to deal with this with constant communication back and forth with the client, showing them mockups, is this what you wanted? No? Ok, let's talk about how we need to change it before I do the work of building it for real. And so on.
3. How do I make sure he pays me and doesn't just disappear?
Choose your clients carefully, and don't bill a lump sum at the end: invoice on a regular basis throughout the project, and if the payments stop so does the work.
Established businesses rarely try to stiff you; they may delay payment for a few months but they'll always write a check eventually. Individuals are trickier; you have to get a feel for whether they're trustworthy (just as they have to do for you) before you get into bed with them. Many freelancers mitigate this by asking for a down payment before starting work. I don't bother with this: if I don't trust them enough to pay the first invoice I shouldn't be working with them in the first place.
(But I don't often work with individuals anyway, because those tend to be the worst jobs: they often don't know what they're doing so I have to spend more time educating them than the job is worth.)
In the worst case, as long as you have a written contract, their name, phone, and mailing address, and records of your invoices, you have enough information to send a collections agency after them. (Don't bother with small claims court, it's a waste of time.) Collections agencies take a huge cut, but it's better than nothing; the few times I've had to resort to this, the mere mention to the client that I was going to turn them over to collections was enough to get them to pay up immediately.
There are dozens of sample contracts available online; google a bunch and read through them to get a sense of what's commonly included.
posted by ook at 12:05 PM on May 13, 2011 [2 favorites]
1. How do I decide the price?
I never, ever, ever, ever do fixed-bid projects. I charge an hourly rate, and if the client doesn't like that, they can go hire someone else. I'll do estimates, and I'll scale the work towards a target budget when necessary, but I will not commit to a fixed bid under any circumstances.
I have never had a client balk at this. (I do have one client whose corporate management requires them to engage only in fixed-bid projects, so what we do is contract it out for an outrageous worst-possible-case-then-double-it amount, then I bill them only for the hours I actually end up working -- more or less what MrFTBN suggests above.)
The problem with fixed-bid projects is that you have to spend a tremendous amount of time up front scoping the project: figuring out what exactly will be included, how many revisions will be allowed, and so on. Projects always change while you're working on them, there are always new ideas or late additions, and if you're working on a fixed bid you either have to suck it up and do them for free or renegotiate a contract update. The incentive is for the client to squeeze in as many last minute changes as possible while they've still got you, because it's all free to them.
When you're hourly you don't have to worry about change requests: they're just more hours. Keep them informed of how much they're spending, and the incentive will be for them to draw things smoothly to a close.
Either I need to prove how long it took me
If they trust you enough to base some part of their business presence on your skills and work, they need to trust you enough to accurately report your hours. (And you need to repay that trust by in fact accurately reporting your hours.) At the end of the day either they'll feel like they got their money's worth, or they won't; that's going to be down to the quality of your work more than the number of hours.
2. How do I make sure the requirements are clear, and that the client and I agree on them?
Well, if you go hourly, this becomes almost a non-issue. I tend to deal with this with constant communication back and forth with the client, showing them mockups, is this what you wanted? No? Ok, let's talk about how we need to change it before I do the work of building it for real. And so on.
3. How do I make sure he pays me and doesn't just disappear?
Choose your clients carefully, and don't bill a lump sum at the end: invoice on a regular basis throughout the project, and if the payments stop so does the work.
Established businesses rarely try to stiff you; they may delay payment for a few months but they'll always write a check eventually. Individuals are trickier; you have to get a feel for whether they're trustworthy (just as they have to do for you) before you get into bed with them. Many freelancers mitigate this by asking for a down payment before starting work. I don't bother with this: if I don't trust them enough to pay the first invoice I shouldn't be working with them in the first place.
(But I don't often work with individuals anyway, because those tend to be the worst jobs: they often don't know what they're doing so I have to spend more time educating them than the job is worth.)
In the worst case, as long as you have a written contract, their name, phone, and mailing address, and records of your invoices, you have enough information to send a collections agency after them. (Don't bother with small claims court, it's a waste of time.) Collections agencies take a huge cut, but it's better than nothing; the few times I've had to resort to this, the mere mention to the client that I was going to turn them over to collections was enough to get them to pay up immediately.
There are dozens of sample contracts available online; google a bunch and read through them to get a sense of what's commonly included.
posted by ook at 12:05 PM on May 13, 2011 [2 favorites]
BTW, if you'd like a copy of my freelance contract, memail me. It's only a page an half - very straight forward. It's not original, I downloaded from some freelancer who made it available.
posted by COD at 12:46 PM on May 13, 2011
posted by COD at 12:46 PM on May 13, 2011
- Seconding the"pad" your estimates advice - I double then I add 25%. Which is about right for me as I tend to be optimistic
- I prefer to do fixed price - but I tend to separate the "writing the requirements" job and "actually doing it" part, and quote them separately. I always invoice 50% upfront. (the reasoning behind fixed price is that you should be selling at the right value for the customer, not based on the effort for you - this also assumes that you're able to deliver enough value)
- remember invoicing does not mean getting paid right away. I include a provision saying that bills must be paid under 30 days - and then set up reminders to check that payments actually went through.
- communicate a lot, and keep explaining the process along the way - if something needs to be renegociated, do it as soon as possible.
posted by motdiem2 at 1:19 PM on May 13, 2011
- I prefer to do fixed price - but I tend to separate the "writing the requirements" job and "actually doing it" part, and quote them separately. I always invoice 50% upfront. (the reasoning behind fixed price is that you should be selling at the right value for the customer, not based on the effort for you - this also assumes that you're able to deliver enough value)
- remember invoicing does not mean getting paid right away. I include a provision saying that bills must be paid under 30 days - and then set up reminders to check that payments actually went through.
- communicate a lot, and keep explaining the process along the way - if something needs to be renegociated, do it as soon as possible.
posted by motdiem2 at 1:19 PM on May 13, 2011
Here's the Google result for a search on "contract for freelance software project." I haven't read the links, but there are several that mention a contract template.
After you fill in any form, it's important to have a lawyer look it over. (IAAL) Find one who has experience drafting these sorts of agreements. Since you know a lot of what you want and will bring in a draft, it shouldn't be terribly expensive, and you can avoid the sorts of traps that will be obvious to an experienced eye.
posted by KRS at 1:25 PM on May 13, 2011
After you fill in any form, it's important to have a lawyer look it over. (IAAL) Find one who has experience drafting these sorts of agreements. Since you know a lot of what you want and will bring in a draft, it shouldn't be terribly expensive, and you can avoid the sorts of traps that will be obvious to an experienced eye.
posted by KRS at 1:25 PM on May 13, 2011
Response by poster: Thanks--lots of helpful advice here. I'm going to ask for hourly pricing, and offer to set a maximum (as MrFTBN suggests) if the client objects.
I didn't think about charging for working on the requirements, but that makes sense. It seems obnoxious to charge for an initial meeting before I've even agreed to work on the project, but charging later for revisions to the requirements, demonstrations, etc. seems fair.
posted by Chicken Boolean at 7:09 PM on May 16, 2011
I didn't think about charging for working on the requirements, but that makes sense. It seems obnoxious to charge for an initial meeting before I've even agreed to work on the project, but charging later for revisions to the requirements, demonstrations, etc. seems fair.
posted by Chicken Boolean at 7:09 PM on May 16, 2011
This thread is closed to new comments.
1: Only you can really decide what your time and this project are worth. Others on here may be able to help you with market rates for freelance coding. Where you fall on the range of market rates will really depend on the extent to which you are uniquely qualified to perform the work (which includes not only coding but also working with the client, being available to take calls and do demonstrations, and so forth).
2: Get the requirements in writing. Get the client to sign them. In the same agreement where you write the requirements, make sure that you include language to the effect that you will bill hourly for work outside of the requirements. Make the hourly rate something that's worth your while.
3: Take half up front. Put it in Escrow if you like. Don't do any work unless you have half up front. Also, bill regularly for work outside of the requirements. Don't surprise the client with an big invoice at the end of the project; give them some warning that a) you mean to enforce the letter of the requirements language in 2, and b) the work you're doing outside the requirements has value.
posted by gauche at 8:56 AM on May 13, 2011