The PHP podcast where everyone chimes in.

Originally aired on

November 7th, 2016

056: Hourly vs Value-Based Pricing

There are two seemingly contradicting philosophies about how to charge clients for programming work. The hourly camp suggests that the client is paying for your skill and hiring you for your time. The value-based pricing camp suggests that the programmer should price a project based on its value to the client instead of the hours it will take to build it. Today we chat about these two ideas and discuss the pros and cons of both.


Hourly vs Value-Based Pricing Show Summary

Time-based pricing

  • Resolution could be hourly or daily
  • Allows flexibility: bill your client for the hours you work
  • Requires you to keep track of your time
  • Was that 10 hours of actual development, or 10 hours of replying to emails?
  • As you get better and you can do things faster, you actually earn less
  • Safe model if value of work is speculative/experimental

Value-based pricing

  • Value of your work is determined by your client, not you
  • Charge your client a percentage of the expected value of what you produce
  • Fixing a major security hole in the right client's product make be worth a huge amount to them, even if it only takes you an hour to fix
  • Billing by the hour pits you against your client:
    • You want to bill for as many hours as possible
    • Your client wants you to charge them for as few hours as possible
    • Value-based pricing puts you both on the same side
  • Using value-based pricing, your client should see the money they spend with you as an investment, not a cost
  • Many SaaS products use value-based pricing e.g: GitHub. Different users receive different levels of value from the same or similar product and pay different prices accordingly

How can we transition hourly clients to a value-based model?

  • As speculative/experimental clients become more stable, now is a good time to change
  • Start changing your model with new clients
  • Use a new project as an opportunity to try something different - don't try to change mid-project

How can we apply value-based pricing to refactoring legacy code?

  • It depends on the legacy system:
    • If the legacy app is important/frequently used or where defects have high potential cost, it is an easy sell
    • If the legacy app is not so important/less frequently used, its a more difficult proposition
  • Compare refactoring legacy code to:
    • The cost/risk of writing a new system
    • The cost/pain of maintaining a brittle legacy product

Sammy Kaye wraps up with

Developer Shout-Out

Thank you, Patrick McKenzie for educating developers on value-based pricing. A $50 Amazon gift card from Laracasts is on its way to you.

Shout-out sponsored by Laracasts


It's like Netflix for developers.


Keith Casey Jr

Tim Lytle

Mike McDerment

Show Notes Credit

Chris Shaw

Thank you Chris Shaw for authoring the show notes for this episode!

If you'd like to contribute show notes and totally get credit for it, check out the show-notes repo!