– we create awesome web applications

2008 was the year when we finally switched to full time consulting. And like all consulters we faced the problem of correct pricing. There are two well-known ways to charge a customer: per-hour rate and fixed bid quote, and several combinations of them.

Per-hour rate.

Everything is quite clear here. You just charge per hour rate no matter what. Your customer wears all risks. Per-hour rate is good for short-term consulting projects, like deployments, launch reviews, etc. If you're going to work on a project that takes more then 10-15 hours, you will need to estimate the required hours to accomplish the tasks. And, obviously, meet this estimation.

So, you calculate estimations. Actually, you always do an estimation, it may be time, it may be money. But you always estimate. Because every customer needs to be sure that she has a budget to hire you.

Fixed bid.

The Dark Art of Realistic Time Estimation is something that anyone can learn. The only question is how much time and money are wasted until you learn it. Because you wear risks in such a case. With fixed bid you can get more money then working on per-hour basis. But also you can loose money, or actually time, working for free because of wrong estimation. Give an expensive quote and customer goes to other developers, give underestimated quote and work for free. Sounds like a dangerous and loose-loose situation.

Sometimes, preparing a realistic fixed bid quote requires several hours or even days of research and planning. At the beginning we did a time consuming planing for free, just to give some number to a potential customer. Sometimes customers just ask for a quote and don't mean to work with you, they're just curious about your quote.

Save your time.

We've found a way to save our time and filter such customers. We make very very rough estimation that sometimes just a price range, which takes 2-4 hours maximum. If the price range matches customer expectations we proceed with exact quote. This is the first-level filter. Obviously, to issue an exact quote we make general software designs and discuss implementation of complex parts. If a quote preparing takes more then 5-7 hours we charge our customer for working on it. Customers that don't agree to pay for issuing fixed bid quote don't pass second-level filter.

In such a way we get only serious customers that really want to hire us and have their projects done. And we always want to work with them. Often, we can reduce a final price by reconsidering our approaches, changing some requirements, reworking flows, etc. We always find out a way to work with these customers, and they always find out a way to work with us. These are high quality customers, and we enjoy every minute of working with them.

Experimental approach.

There is another approach that sounds quite fair. Risks are shared between customer and consulter. Let's say the original estimation is 10 days, and you charge say $800 per day. The total price of $8000 is split into 2 parts: per day part, say $3500 ($350 per day), and final part $4500. Final part is paid at the end of the job. If something bad is happened and you work 12 days instead of 10 days - customer pays you extra of 2x$350, final part remains unchanged. If you complete the project in 8 days instead of 10 days - customer pays you 2x$350 less, and final part also remains unchanged. So if things got complicated, or you underestimate the tasks you get lower average per-hour rate and customer pays a bit more. If you work faster - you get higher average per-hour rate and customer pays less and gets the project early.

Slow and expensive.

We heard a lot that large companies charge 5 times more then we do, work 3 times slower, and produce ugly unmaintainable code. And they still get customers. So what's the secret here? I can think about only one reason: they're big. Sometimes customers think that if you're small you will disappear in a nearest future, and no one will be able to take care of the project. This is ridiculous when you're talking about Ruby On Rails.

Are there other reasons?

comments powered by Disqus