Software Pricing Battle Royale

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:

1. Time
2. 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.

I know of which I write.

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