Software Pricing Battle Royale
Hourly Billing vs. Value-Based Pricing: What's the morally right way to bill for software development? Two software business superheroes face off.
There are many ways to bill for software development work:
- By the hour
- Fixed bid
- Monthly retainer
- Hourly not to exceed
- Productized services
- Level billing
- Value-based pricing
- Subscription (SaaS)
- Pre-packaged software
Fundamentally, though, it's a question of what you are charging for. And there are really only two things you can charge for in software development:
- Time
- Output
Either you charge clients for the time you spend working on their projects or you charge for the finished product.
Time
Billing for your time is the more common–and less risky–of the two options.
It is also the most limiting. It's low risk, low reward. High floor, low ceiling. Whatever analogy you prefer.
Billing for your time is limiting because time itself is a finite resource. No matter how efficient you are, there are only so many hours in a day, days in a sennight, sennights in a fortnight, fortnights in a bimester, bimesters in a triennium, and trienniums in a saros.
At the same time, you don't have to risk losing your shirt over one bad estimate.
Output
The easiest way to tell whether you are charging for your time or your output is the terminology you use when a client/customer asks how much something will cost.
If you give them an estimate, you are charging for your time.
If you give them a price, you are charging for your output.
Most software developers dismiss this approach out of hand. Chances are they've been badly burned by a client who insisted on a fixed price, and–desperate for the work–they agreed. Most likely, though, they calculated that price based on the time they thought it would take to complete the project. Which they underestimated because software developers are eternal optimists. And then they got killed on scope creep because they were working through a punch list of tasks.
The problem with this "time and materials" approach to fixed bid pricing is that it is too me-focused. How much time will it take me to do this project? It's the mindset of someone conditioned to bill for their time.
And it's why it fails miserably when you start billing for your output.
Instead, you need to start thinking in terms of the value to the client or customer. What's the value of this solution to the customer? What business outcome are they seeking? And then–and here's the critical part–you give them a price for the business outcome, not the software output.
That's how you combat scope creep.
The Advocates
There are pros and cons of both approaches, some of which we've already covered.
What I find more fascinating, though, is that one can make a strong moral case for each approach.
And so I present to you competing views from two of the savviest business guys in the software development world:
- Armen Stein: longtime Access MVP and president of J Street Technology
- Jonathan Stark: author of Hourly Billing is Nuts and web comic Ditcherville
The Moral Case for Hourly Billing
The Moral Case for Value-Based Pricing
