Ask HN: Alternatives to per hour pricing | Hacker News Reader

Ask HN: Alternatives to per hour pricing

7 pointssid63769 comments

My friend(and really, its a friend and not me ;-)) has a web development consultancy. It's a relatively new company with recent college graduates as interns and a couple of friends the only employees. He's burnt his hand enough with the per hour payment model that he has followed till now for each project that he takes up. The estimates are generally wrong and the interns usually give enthusiastic and unrealistic estimates. He's looking for alternate strategies so that he can devote more time on development. What pricing strategies have worked/not worked for you? Can you suggest some other models that have worked for you?

Just to clarify this pricing strategy is for per project. Currently he gives an estimate in hours for each project and charges them the per hour rate.

View on HN

>"It's a relatively new company with recent college graduates as interns"

Making accurate estimates takes experience - and the only way to get it is to pay the dumb tax -- make your estimates, land the job, and complete the work. Of course a person can reduce the dumb tax by analyzing billing against the estimate and the more fine grained by task the estimate and time tracking are, the less dumb tax you will pay.

"Hourly not to exceed" is a model I have used in my work - which is not programming. Again breaking down the contracted fees into tasks helps because I can know if I am falling behind in the early stages and cap the blood loss. Of course, I have also used flat fee and straight hourly as well.

In my experience fee structure should be based in part on the client's needs not yours. A client who drops the spec on your desk can handle a flat fee. The person who is going to throw wrenches in the works, gets hourly.

Lastly, fee structure is a way of selecting the right clients at the right price. Hourly weeds out exploitive clients. Fixed fee allows "buying the job" when you need cash or when the client relationship is desirable.

Have to disagree here. Never ever use not to exceed pricing. This is the single most dangerous type of pricing.

If you do it faster you have no benefit and if you go over you really lose badly.

With fixed fee if you are under you make extra which balances the times that you are over.

When you first start out you must use time and materials (hourly). Report expenditures at least weekly or even more often, so the client always knows where he is at and can prioritize accordingly.

Once you figure out what you are doing and have a repeatable process you can do fixed fee

There's no reason to disagree. I wasn't advocating hourly not to exceed - just offering it as an alternative.

Doing it faster with straight hourly does not offer any more benefits than hourly not to exceed - the benefit of doing it faster in both is improved cash flow if a milestone payment model is used.

Hourly not to exceed provides a solid feedback loop on estimates and allows the development of better estimating skills. Like "buying a job" with a low flat fee, it may provide soft business benefits depending on circumstance.

Wait wait wait, if it's per hour, estimates don't matter. Do you mean per project?

yeah per project. Sorry if my question was misleading.

The you should try per hour. Example:

Project X has an estimate of 200 hours, but if at the end of the project 230 hours are used, you bill 230. This is usually the best way to protect yourself from late changes, feature creeps and undecided clients. This approach also puts more responsibility on the decisions made by the client.

If your friend already has some proven track record, clients should trust him as a professional.

The downside to hourly payed is that some clients don't like it and it's understandable. A failed project is not only the responsibility of the coding team.

Here's a neat article about this: http://www.webdesignerdepot.com/2010/10/charging-per-hour-vs...

If you use an agile model you will develop the most important features first. What this does is every week keeps you focused on the top priority and ensures that when the budget runs out, the most important features will be done.

The reality is that if there are 100 units of work and only 80 units are possible based on the budget, either the client will be unhappy because you told him 100 units were possible or you will be unhappy because you did 100 units of work for 80 units worth of pay.

It is much better to just do the highest priority 80 units first and then see if the last 20 units are really necessary. When they actually have a working product in front of them, often times clients will realize it isnt worth delaying to get the last few bits.

Don't let interns establish quotes, they're not sales people.

The CEO should own the revenue stream, make him approve any quote (or at least anything spanning more than 1 days worth of work).

I agree about quotes, but I think the interns were being asked to estimate their time, and that's a good thing provided that the manager's initial adjustments to their estimate are discussed with them, they get ongoing feedback about their performance against their estimate and that there is a debrief to figure out why the estimate was inaccurate.

Reply on news.ycombinator.com