Hacker News Reader

Comment by evdawg | Hacker News Reader

Never ever ever ever __ever__ do a fixed amount for a project. You will get screwed.

I've made this mistake twice in my life; both times at the end of the project it worked out to something crazy like $5/hr along with sour relationships with both clients.

An hourly rate is always fair, for everyone. The client gets what he pays for and you get paid for what you give. No more, no less on either side.

View on HN

LOL, you just don't know how to estimate how long it's gonna take, or you don;t specify what needs to be done well enough.

Lots of people work for a fixed price with happy clients and they end up being happy with the outcome too (myself included). The key to everything is to be good at specifying what needs to be done, and then be good at estimating how long it will take you to do it.

Also, lots of clients do not want hourly, because THEY feel it is unfair. They do not see you working, and you could be taking them for a ride.

Specifications, paradoxically, always lack specificity. There are always lots of things you can get into an discussion about. A good client understands that specifications change, that work is incremental and that you wish to be paid accordingly.

Every experienced developer should know that nobody knows how to estimate how long something is going to take. Even the best developers I know always fudge their numbers by a factor of 2 and that is after they have sliced the work down to parts that take at most 4 hours and used all other tricks in the book to get decent estimates. You add everything, add 50% for writing the tests (either before or after the actual code, that doesn't matter), add another 50% for meetings, discussions, etc., add another 15% for writing documentation and then double it all.

I will never take a fixed-price job, unless I'm sure the client is reasonable in his expectations and I can apply the above calculation while still ending up with a decent hourly rate. I'm currently employed, but my employer isn't doing too well...

I thnk we are talking about the same thing... Based on estimations, it is always a goods idea to add a certain room for error, additional expenses, etc...

I did not say multiply $20 times the number of hoiurs, I just said that you need to derive your fixed price based on your estimation (not DIRECTLY based), which in turn is based on the specifications/requirements.

So we are in agreement. My beef was with the assumption that the service provider always gets screwed if they charge a fixed price; my point was that that does not need to be the case, if you follow a solid process to give your estimate.

False. I freelanced for almost two years and roughly 50% of my gigs were fixed price and I usually ended up making > $100/hr when it was all said and done. Here are the keys:

  - have a solid spec
  - build up a library of code you can reuse
  - carefully evaluate the reasonableness of the client

The truth lies in between. It depends on what you sell: your time or your knowledge.

I would never contract someone on hourly basis, I'm always trying to buy someone's knowledge not his time.

I'm trying to build partnership not contractorship. If you sell your time you are like an employee; If you sell your knowledge you are like a friend.

I second that.

Never do unknown amount of work for a fixed amount of money. Forget about "good guys" and "friends". You either charge them per hour or (if fixed job) control the contract with detailed requirements. You deliver that - you get paid. Charge per milestone. Split new features/changed requirements and your bugs. Charge more for new features. Always emphasize the fact it is not a bug, even if you are willing to do it for free. NEVER do life-time free maintenance of the project - set and meet the deadlines.

ALWAYS CHARGE.

People who can not organize and manage the process of development properly are deserved to be charged to the maximum extent.

Charge, charge, charge!

Almost everything we do is fixed-price. I can't think of a client that has screwed us. But we go out of our way to find ways to work ("for free", gasp!) with clients; nothing is more valuable than the relationship.

You probably also manage your hours well and have provisions for work outside of scope. Going hourly is much safer for someone new.

You're probably right, but the thing I learned from the first successful startup I was involved in that has stuck with me my whole career is the marketing power of customer service. It kills me when we can't make a client happy.

Maybe the trick is, pick good clients.

(The startup was an ISP, in 1996. Even in 1996, an indie ISP was hard to differentiate from the majors and incumbents. Mike and Tracy, the guys who ran the company, managed to build an unassailable reputation for customer service --- to this day, I don't understand how they did it, because I don't see how we did anything different from the other ISPs, other than to tell ourselves we had awesome customer service. But our ISP kicked ass up and down the block based almost entirely on that reputation. I'd love to get some of that mojo at Matasano.)

Amen brother! A happy customer is a great source of revenue over time even thoguh you may take a hit from time to time. How big a hti you take depends on how good you are at what you do, and how good the client is (as far as helping you draft good specs for them).

I always do a fixed rate for my work and go out of my way to help customers, sometimes years later, with simple problems for free.

Guess who they call when they have another job? Me. Guess how much more they're willing to pay than new clients? A lot more.

Customer service being a first priority is not just a marketing phrase - it really does make a huge difference.

That being said, it is very important to define a clear scope, explain how much extra certain pieces would cost if they go out of scope, etc. Most clients are very receptive to changes in the quote - note the use of the word QUOTE - when the scope changes and you explain why it will cost more.

Reply on news.ycombinator.com