By Peter Bell

It's not about what you build, it's about how much it costs

If you look at many website development shops, they tend to have a price range that they specialize in for their projects. Some shops specialize in small maintenance work and are quite happy to do $100 or $200 projects and to make it up in volume. Some offshore shops will (try to) build almost anything you want for $5k. Many web shops in the US have a "sweet spot" for projects between (say) $5k and $50k, and then there are plenty of businesses that really don't bother with anything much under $100k.

In my experience, it is much harder to change the price point of the projects you sell than to change the cost of building the projects. Confused? Let me explain . . .

Let's say you work at a (fairly common) smaller web shop that builds cms's and e-commerce apps for small to medium sized businesses. Most of the projects you do are $15k - $35k with the exception of the occasional $100k whale and some maintenance work that you do for previous clients. Let's say that tomorrow you came up with a breakthrough that would allow you to spec, build, tweak and deliver most of your apps in a day or less. What would you do?

In theory you'd try to estimate the elasticity of your demand curve and would price the projects above your cost, but how much above would depend upon what would maximize your profitability (assuming a rational pricing strategy - and yes I *know* that's a big assumption!). So, if you could make the most profit by churning out projects, you might start to sell the same projects for $5k on the basis that if it could bring you twenty times the volume, you'd be more profitable than just doing twenty $25k projects a year. The problem in that usually there is very little flexibility in your sales process. In my experience the sales process for $2k or $20k or $200k projects are fundamentally different and companies that try to move from one to another usually fail.

If we take our small web shop selling $25k projects, they might have 1-2 sales people (one is often the owner or a partner) doing maybe 5-15 meetings a week. Typically the median sales cycle will be 3-4 meetings from the first meeting to signing a contract or picking up a downpayment, and they'll be able to close (with one full time sales person) 3-5 projects a month which will probably support a dev team of 3-5 full time developers. If they could suddenly build the same apps profitably for $5k, if they actually changed their pricing to that, they'd probably go out of business!

Why? Simply because unless their sales team could handle twenty times as many meetings (not possible!), they wouldn't be able to close the extra projects required to profit from the lower prices. Sure the closing ratio might move from 1 in 3 to 1 in 2 or even 2 out of 3 (unlikely), and the sales cycle might become a little shorter, but the chances are that they couldn't substantially change the price point of their offerings even if they wanted to - the sales process wouldn't support it.

Of course, if they could start selling projects by the phone or online, they might be able to scale the sales, but the skills required to sell something online, by phone and in person are completely different and a business that tried to move it's primary revenue stream from one sales process to a substantially different one would be taking a huge risk.

As I look at the businesses I've been involved with, the only shift I've really been able to make to a lower price point was when I started selling on a wholesale basis. By allowing our design partners to do most of the sales and bring us 5-20 projects a year we were able to cut the sales effort per project and therefore the pricing per project substantially.

What has your experience been of the changes (or lack of them) in the kind of price points of the projects your consulting firm has undertaken?

Comments
I think an alternate solution would be to keep your prices high. If the small business was able to build what used to take two weeks, in two days, they would be freeing 8 development work days. These work days could, like in your examples, be used to just build and configure a higher volume of projects at a lower price. However, I think the best solution would be to take those 8 days and spend them improving the product and the process. After a few months of full time improvement, the product could almost sell itself.

What do you think?
# Posted By Jordan Sherer | 11/10/08 6:28 PM
@Peter,

I really like the approach of having design partners out there making sales for you and giving them a wholesale price on a product that is developed very fast. If you have enough of these partners out there pushing the product, it's almost like having a contracted sales team out there bringing you business. I've been working on reducing the amount of customization for the generated apps that I'm currently generating and I think when I reach that point I will be using a similar approach with the strategic partnerships.

Keep the posts coming!!!
# Posted By Hatem Jaber | 11/11/08 8:45 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.005.