Charging by the hour/project [closed]

Question

This is related to a question I asked earlier - How to end a relationship with a client without pissing them off?

What are your obligations when charging by the hour vs charging by project? If you agree to take on a project, give a rough estimate that it might take 10 days for you to work on and charge £X per hour - are you obligated to work for free after those 10 days are up and you have still not managed to complete your project due to unanticipated issues? What if you have delivered the project but bugs are found - should you fix these bugs for free if the 10 days are up or should you charge your client?

Also, for the above project, what should be the result when you start on the project, but after the 10 days for whatever reason you have to give up and tell your client that you cannot do it anymore? I realise that this does nothing to build your reputation and relationship with the client but are you obligated to pay back the money paid to you or do you just deliver the half/nearly completed source code and help them find someone else to complete it?

The reason I am asking the above questions is because I am very new to freelancing and would like to know how to deal with the above situations if they ever crop up. Thanks!

Answer 1

If you agree to take on a project... work on and charge £X per hour - are you obligated to work for free after those 10 days are up and you have still not managed to complete your project due to unanticipated issues?

No. £X per hour is £X per hour. Clearly, you've never had complex jobs done on your home or boat.

Inability to estimate means nothing. Nothing.

£X per hour is £X per hour. Until the job is done or the client says "you're fired." (or "you're sacked". I'm a Yank, so I don't know what they say in the UK.)

What if you have delivered the project but bugs are found - should you fix these bugs for free if the 10 days are up or should you charge your client?

Depends on the bug. You must do root cause analysis. Bad (or incomplete) specification is mostly their problem. Unanticipated technical wrinkles is par for the course -- they pay. Dumb coding mistakes is your problem.

you have to give up and tell your client that you cannot do it anymore?

Ooops. That's unprofessional. If you have to give up, you've really made a terrible, terrible mistake.

I realise that this does nothing to build your reputation and relationship with the client but are you obligated to pay back the money paid to you or do you just deliver the half/nearly completed source code and help them find someone else to complete it?

Sigh. At this point, you've behaved so poorly that nothing much matters. You should really find another career if you can't follow through on your contracts. Seriously. Rethink your life.

Half-completed software is worthless. No one will "complete it". They'll explain that you're an idiot (because you are) throw your code away and start again from scratch.

You need to do the following.

1. Cut the requirements back to something final, deliverable, and usable.

2. Create that final, deliverable, usable thing. Even if it's not the original grand scheme.

3. Charge for that deliverable, usable thing.

4. Transition the backlog of undeliverable stuff to someone else.

Code that cannot be used is useless. Indeed, it's a cost.

You and your customer will waste time trying to "transition" the half-completed code to someone else. Emphasis on waste. It's easier for most people to start from scratch than to start from half-finished.

Answer 2

What are your obligations when charging by the hour vs charging by project?

Essentially the same. Be professional.

If you agree to take on a project, give a rough estimate that it might take 10 days for you to work on and charge £X per hour - are you obligated to work for free after those 10 days are up and you have still not managed to complete your project due to unanticipated issues?

No - as long as it's roughly 10 days, then you're fine. I would define roughly 10 days as anywhere between 50 - 120 hours at the extreme edges. Anything over 120 hours (a 50% overrun) is pretty much beyond the pale.

Though "unanticipated issues" leaves a lot of vagueness. Experienced professionals anticipate a lot more issues than new developers. However, if the client knows you are a new developer (and know they are getting a significant discount because of it) then there's some wiggle room here.

What if you have delivered the project but bugs are found - should you fix these bugs for free if the 10 days are up or should you charge your client?

Bugs? Yes - you should fix those for free. You're not being paid for 10 days to produce broken code.

Now, again, "bug" is a bit vague. There are show-stopper bugs (like, program doesn't run - obviously your fault) and edge-case bugs (program truncates text on Turkish-localized Windows with Chinese IME enabled - not really reasonable). Most fall somewhere in the middle, but the burden of proof is on you.

There's also specification bugs - these are the hardest. You'll have to use your judgment as to whether you should have reasonably anticipated, questioned or implied the specification change. Again, I'd put the burden of proof on you.

For a 10 day (80 hour) project with a green developer, another 10 - 15 hours of bugfixes wouldn't be too much to ask. Anything over that, I would try to work out payment for - though I'd probably do another 5 to 10 hours for free before firing the client.

Also, for the above project, what should be the result when you start on the project, but after the 10 days for whatever reason you have to give up and tell your client that you cannot do it anymore? I realise that this does nothing to build your reputation and relationship with the client but are you obligated to pay back the money paid to you or do you just deliver the half/nearly completed source code and help them find someone else to complete it?

You give the money back. If you can't finish the project, it's likely you can't judge half-completed. If the client hired you, it's even more likely they can't judge half-completed. If you can find someone else to finish it, you can subcontract to them - the difference in what they charge you and what you already made is your profit (or loss).

In the end, it's often better to bend to the client and chalk it up as a lesson learned. After a while, you'll be able to spot the "problem clients" and avoid them (or upcharge them) at the beginning. You'll also learn to estimate a bit better, build bugfix costs into your pricing, etc.

As a student developer, you do have some leeway. No one is likely to sue you over the pittance you charged for a 10 day project. You'll never get any business from that client (or his friends) again - but, since they hired a student developer, it's likely they only want cheap labor and don't understand what it actually costs to hire a good developer anyway. You're not losing out on much in the future except headaches - though at the cost of a clean conscience.

My advice? Just finish it up - you'll feel better, the client will feel better, and you'll be a better developer and businessman for it. It's not like it's a years worth of work - and you have all your friends at Stackoverflow and Stackexchange to help. ;)

Answer 3

What you are describing is just "fixed amount or less". This only benefits the client, so if you are making the bid I have no idea why you'd work that way.

• Hourly rate - An hourly rate can be used when the client knows they haven't made up their mind about some things, and they agree that the project is a bit open-ended - but this must be agreed in advance.

• Fixed rate - Use if the client knows exactly what they want. If they do, but you can't bid it to a fixed amount, you don't really have any business making bids yet. Don't make the client pay for your inexperience.

If you follow this, you won't end up in a situation where you don't know what to do. If you have to give up, discuss with the client and treat like a resignation or partnership dissolution. Refund all the money and deliver nothing, or offer the partial project in exchange for partial payment.

It's tempting to apply hourly rate whenever there is some uncertainty, but it should only be used when the client is the wishy-washy one. If you are experienced but still have significant unanswered technical questions, then be open about this with the client upfront.

And, get a contract, or it's only a matter of time before you run into problems.

Answer 4

I'm no lawyer but the answer to both situations depends on what you have agreed contractually with the client. I saw in your earlier question that you were working without a contract which seems rather dangerous for the exact reasons you've raised here. No written contract certainly doesn't mean no binding obligations. It's good to have all this sort of stuff figured out before you begin your working relationship so that if any issues arise they can be resolved professionally and amicably.

Answer 5

Legal reasons aside, this is a service business after all and you live and you die by references. It can only take one bad one to give you a bad rep. I can only take one really satisfied customer to give you lot's of other work. So apply the golden rule, treat your customer as you'd like to be treated, within reason. People remember and value people who go a little above and beyond their "duty".