How to price software projects

Here is what I learned (in random order):

Price the outcome, not the scope.

Software is never the goal, there’s always a desired state of the world that the client has in mind.

Figure out what success would feel like.

Figure out what a failure would look like.

Find the budget they have in mind (how much they want to invest).

Then, price the outcome as a fraction of that price that allows you to deliver it with enough margin that you have the freedom to find the best way to do it.

Don’t limit yourself to the price you’d pay.

If I have a 10-million-dollar problem (opportunity), I’d be willing to invest 1 million for a decent shot.

If my supplier is afraid to quote more than 250k, I’d not be certain that they can deliver at the level I need.

Fixed price beats hourly.

If you price for the outcome and find mid-way through the project that you need 2 weeks of DevOps work, guess what you can do?

Hire a DevOps engineer and put him on the project.

What don’t you have to do?

Negotiate a scope extension with your client every time that happens.

At the start, you don’t know what to build.

Don’t commit to a fixed scope.

Commit to an outcome.

An outcome can be achieved in many different ways.

A fixed scope can only be delivered in one.

The price has nothing to do with your cost or scope.

It only has to do with the outcome for the client.

It’s up to you to reverse-engineer how to get that outcome so that the project is profitable for you.

The faster you are, the more expensive it should be.

If I’m bleeding sales because my website is slow, I’d pay 100k to have that fixed in a month.

But I’d pay 250k to have that fixed tomorrow (because the recovered sales will be worth the extra cost).

If you price for the outcome … faster = better.

Better = more valuable = more expensive.

Price the discovery phase.

Sometimes, clients don’t know what they need, and when the situation is too murky, you must invest time and resources in researching a potential solution.

Sell that process.

Be transparent about the value.

If you’ve done a good job in finding the outcome, that should be easy.

The value is not “I’ll have 5 engineers working on it”.

The value is the increased revenue, cost savings, improved customer satisfaction, competitive advantage, and operational efficiency they’ll receive.

Wrapping up …

I had more points, but this email is getting hella long.

Let me know if you’d like me to unpack any of these concepts in more detail or if you’re interested in part two.

I appreciate you for making it all the way to the end and I wish you a fantastic week!

Best regards,

Taj