Guidelines for small project pricing

I really enjoyed reading Guidelines for Small Project Pricing. There’s some good tips in there for anyone freelancing or running a small business.

Pricing and quoting can be a tricky thing, and a lot of it comes down to terminology and understanding. There’s no one way to do it, but however you choose to do it you’re likely to find some good tips in the article.

A couple of things I especially liked:

Negotiate scope, not price – I like this because I do it a lot myself. Breaking a quote down into a few chunks makes it easy to show the client where the complex areas are, and can be a good way to help them cut out unwanted features. If they see some tiny “nice to have” feature consuming 80% of the cost then odds are they’ll be happy to drop it.

Your hourly rate and time spent do not get discounted as a result – wanting more than you can afford is not a problem that falls onto the vendor. Outside the world of service based companies, it would be laughable if a BMW salesman was faced with a person would really “needed” a BMW, but could only afford a Mitsubishi. These debates should not happen and are a waste of time, if you have a simpler alternative, offer it, otherwise give yourself the luxury of declining the project.

It’s interesting how it’s perceived that tangible goods are harder to barter over than services. Maybe that’s some of the reasoning behind the web shops that run on a conveyer belt of churning out websites for $99?

Clients need to respect that they are buying your time, and the results within that timeframe are a byproduct. If they run out of funding or become too ambitious for their budget, they can’t be allowed to view their project as incomplete and therefore demand to refund.

Accurate project scope is a must. You wouldn’t expect an accurate quote from a contractor if you said “I want a house with a kitchen, bathroom, and living room – how much will that cost me?”

I actually like this more because of the use of the builder analogy – which holds true in software development in many ways;

  • Describing house foundations as a way to talk about good/bad code (this is regarding inheriting other people’s work usually, and runs into my other favourite topic – technical debt)
  • When the spec changes mid project, imagine what a builder would say if mid house construction you said “Oh I’ve decided I need 2 more rooms, just add those on please, it won’t take you much time will it?”

The article is well worth a read, and there’s also some interesting discussions and additional points in the comments.

Posted on Thursday, September 22, 2011 10:46 PM |

Like this? Share it!

No comments posted yet.

Post a comment
Please add 1 and 4 and type the answer here:
Remember me?
Ensure the word in this box says 'orange':