I am the Chief Custodial Technician at Rent Application, a former options trader & passionate QBASIC developer. I like country music, bourbon, Words With Friends, ice cream, Crossfit, Louis CK, and Zooey Deschanel.

Demand Based Developer Pricing

Demand Based Developer Pricing

I write and sell code for a living.

As an individual, have a limited, finite inventory of hours I can sell. This number is often different from the number of hours I want to sell.

Here’s my new pricing model for my freelance developer hours, inspired by:

  1. Supply/demand based pricing models for individual units in other markets
  2. My personal utility curve for dollars

Every week, I have up to 168 hours. I will sell up to 80 of them. The pricing for “Eric Liu hours” is based on the total number of hours that have already been allocated that week, as follows:

  • My first 10 scheduled hours: I charge $30/hr
  • 11-20 hours: $60/hr
  • 20-30 hours: $90/hr
  • 30-40 hours: $120/hr
  • 40-50 hours: $180/hr
  • 50-60 hours: $240/hr
  • 60-80 hours: $400/hr

My hours are bookable up to 6 months in advance, paid at the time of booking, priced at the time of booking. Once time is booked, the fee paid is non-refundable.

Why?

If I work 30 hours per week, I’ll make $90,000/year. That’s a number I’m happy with, at a workload that I love.

Could I make more? Sure. But honestly, the amount of happiness I get out of an extra dollar after $90,000 is pretty small. So I charge more for hours after that.

I charge less for the first blocks of time because:

  • (A) Those are the most important hours for me, because they keep me alive, sheltered, and fed.
  • (B) The lower price ensures I’ll have interested clients.

I charge more for subsequent blocks of time because:

  • (A) Once my basic needs are taken care of, watching my bank account number go up isn’t personally important to me
  • (B) They’re economically more valuable to purchasers of my time (clients are better off when they get more contiguous blocks of time, within reason due to less context switching or less time between sprints).

You could think of my pricing as going roughly from:

  1. “i need to pay my rent and eat ramen”
  2. “love me some steak dinner”
  3. “yeah, i deserve some luxury”
  4. “i don’t want to work, so if you want me to work, please buy me a new car”

How Is This Better For Both Clients And Better For Me?

This lets clients choose how they want their project to operate and makes it possible to engage me at a range of hourly rates.

A client can control price (buy my first 10 hours each week for the next N weeks) with the tradeoff of increased delivery time (calendar time). In return, I get reliable freelancer income, paid up front, booked in advance.

Alternatively, a client can get faster delivery time (book my first 40 hours for the week) with a tradeoff of higher incremental cost per hour. I work more than I want, but in return, my vacation fund gets filled up faster.

I get a system where clients are encouraged to pre-book my work in advance and act quickly because if another client books my hours, then the slow ones pay more for the subsequent hours. If I can’t book my hours, clients benefit from having access to me for a lower cost.

I don’t lock anyone into my pricing, so no clients are forced to buy my expensive hours unless they deem it economically sensible.

The first couple tiers are really quite inexpensive by developer standards, so instead of thinking of this as a “surge price” for lateness, you could think of it as a discount to clients for providing me work when they are of the highest economic utility for me.

When Does This Start?

Now.

I’ll be creating a calendar of available hours with a booking and payment form and linking it here. I recommend booking my time in 4 hour increments, as I have found that to be a productive interval for me to really dig into a problem and make real progress.

If you have questions or comments about my new pricing structure, please feel free to drop me a line.