

Ask HN: Alternatives to per hour pricing - sid6376

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?<p>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.
======
brudgers
> _"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.

~~~
triviatise
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

~~~
brudgers
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.

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

~~~
sid6376
yeah per project. Sorry if my question was misleading.

~~~
tudorizer
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...](http://www.webdesignerdepot.com/2010/10/charging-per-hour-vs-per-
project/)

------
triviatise
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.

------
vladd
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).

~~~
brudgers
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.

