The Fixed Price Trap


There was a time when I would do anything to close a freelance deal. Nowadays I’ve been busy pretty much 101% of business hours, so freelance isn’t my priority, but it might still be for one of you 6 folks reading this. I feel your pain. Back then I was once asked to develop a helpdesk system, which I knew quite a bit about since I had done something similar a few years before. I could not reuse the code, firstly because it was proprietary to the company I was working for back then, and secondly since I wanted to wipe Lotus Notes from my résumé. So I decided I would do it from scratch, in PHP and MySQL – those days you didn’t have the open source fenomenon you see now, so you would either put it together yourself or buy it in a box. I made my price very accessible, as I wanted to get that job very badly. The client found it expensive anyway and said my nephew can do it for less!

É uma cilada, Bino
I should have known

I wish I had respected myself and let his nephew take the job, but I swallowed my pride and cut my already low price in half.

Não me orgulho disso.
Proud of it I am not.

Naïvely, I had no contract signed, no scope defined, I just set out to do stuff. User registration, check. Callout categories, check. Callout workflow, check. Priorities, and so on, check, check, check. One month of hard work later I was quite proud of the outcome. Not just the functionality was there, but, due to my designer’s vocation, the app looked quite good, modesty aside. When I thought it was ready, I got the credentials to get into the client’s network and install the system. All done, tested and delivered! As I billed for my hard earned money, I heard one of the most outrageous things of my whole career:

But, dude, where are the reports? I’ll only pay you after you’ve done the reports!

Notice the plural, the reports. Not only had they never been requested, but any decent report would nearly double the job value. There are retail products that do nothing but reports, and make lots of money, and why should I make them for free?


In an amazing display of emotional intelligence, I walked away. Just kidding, it was immaturity, plain and simple. I left behind the system installed in the client’s network, and as a punishment for not being paid, I did not deliver the reports.


Lessons learned

I didn’t tell this tale to show off my incredible skills as a software developer, designer or project manager. I could count the mistakes Young Me made: accepting nephew competition, not defining the scope, walking away from the project, not asking the fair price, among so many – but let me highlight one in particular, the best lesson I learned back then: working for a fixed price. Don’t get me wrong, there is nothing bad about doing a closed-scope project and fixing your effort’s price based on that scope. In this case, however, you have to be very cautious so the client doesn’t run you over. Closed scope demands very well defined requirements, as well as an agreement among the stakeholders, that makes it clear that the scope cannot be changed without a budget adjustment. Come on, you don’t need an MBA to know that the scope is going to change. You don’t need a contingency in case the scope changes; be prepared for when it does. In my next post I’ll talk about agile projects and why you want your project to be like this.

Leave a Reply

Your email address will not be published. Required fields are marked *