February 15, 2021

It's going to cost four figures

Let's talk about pricing commissioned work on existing open source projects. Or: things I learned from my past mistakes.

A followup to No, “Open Source” does not mean “Includes Free Support”. Buckle up, this is going to be a long one.

Here’s a situation, maintainers of open source projects might find familiar: an email arrives. The sender introduces himself as the representative of a business and would like to ask, if it is possible to adopt (part of) the project to his (very) specific use case. A custom fork, exposing the desired functionality via a commandline switch would suffice. Shouldn’t be too much trouble, right?

Right! It isn’t. Couple of hours tops to write the code. But under no circumstances do I want to have it in the project’s main development branch. Besides, I’m not really going to spend an afternoon, so someone else can cash in on it, am I? This is clearly a commission. I’m going to charge for it. The question is just how much…

WTF
WTF?! Four figures for a patch of maybe 100 lines of code? How do you even justify that?!

In the past, I would have spend an hour or so (spoiler alert: that was already a mistake), roughly sketching out in my head, what needs to be done, estimated how long it would take, multiplied that by an arbitrary industry standard hourly rate, tried to somehow justify the number to myself (second mistake), then send a quote, just to receive one of three replies:

  • That’s too expensive! Forget, I asked.
  • That’s too expensive! Can you make it cheaper?
  • That cheap (would have expected at least double) ?

Great! So, I either wasted an hour preparing for a commission that’s never going to happen, be forced to waste even more hours on negotiating getting paid less for them, or flat out sold myself short. Welcome to the business world, dumbass!

An error in reasoning Charging an hourly rate for a service is a convenient method for writing offers and bills (easy to digest and therefore more likely to be accepted without hassle), making it the obvious choice. But the real value of a service isn't always expressible as the product of hours × rate. At least not without inflating the factors unrealistically.

Lesson learned. Nowadays, I just skip the whole cost forecast thing and send a simple response right away: “Can do. Will cost about four figures. When do you need it?” Sounds brazen? Maybe. But, by my experience, everything else is going to end in tears. Let’s break down that line of thought.

What’s the value of my time?

A common misconception about open source software is that it is developed by hobbyists in their spare time. With a day job to pay for the bills, free time does not have opportunity cost, so it can be bought/must be sold for cheap. That, at least, is what the market theory tells us, but that’s not exactly true, is it? In fact, it is utterly wrong. The opportunity cost of spare time is enjoying life. I, as everyone else, only have one lifetime to spend and I intent to use as much as possible of that, pursuing my own happiness. Work is just a means to that end.

So, if I’m freelancing, which part of my life am I selling? The office hours or my leisure time? In first case, I’m running a business. My price calculation therefore has to cover my cost of living and turn a profit as well. In the second case, the former becomes my baseline, as my bills are already paid and I therefore need a pretty good incentive to turn even more of my lifetime into working hours. Either way, nothing about the involvement in open source software compels me to provide cheap labor.

Bottom line I'm neither a burger flipper, nor do I work at cost. For me, this is a business, not a charity. So yes, my bill includes profit. If it doesn't pay, I'm not interested in doing it.

That being said, I do not charge by the hour for software development. Period. Hourly billing only works when the required time is easy to pre-estimate, track and review by all involved parties, e.g. when consulting on the phone. But it is the completely wrong model for doing any kind of software development. Here, other considerations come into play that go way beyond the “mere” 100 lines of code, I may eventually end up writing. Hence, my four figures “quote” has nothing to do, whatsoever, with the actual time that goes into typing them.

I’m an engineer, not a psychic

I have been doing this for a while now and I never ever came across a single client, who even remotely understood what exactly he wanted (even when having a technical background). Sure, they all had a rough idea of the problem they wanted solved, but the steps to getting there were a total mystery.

Premise The client is incompetent. Always! That's important to note and to prepare for. If he had the necessary expertise for the job, he'd just do it himself, not hire me.

My work always starts with figuring out the interface(s) between my code (to be) and the client’s system, as well as explaining to him what can and can’t be done. That process typically takes days of written correspondence. All of it is scaffolding. None of it will show in the final product, but it is preliminary work that must be done before any of the actual work can happen.

Beware of shortcuts Discussing a project on the phone is faster, but you quickly get bogged down in details and with no written record of what has been said, requested and promised, either party is going to forget half of those details. That's a lawsuit in the making.

When a client contacts me for the first time, I have no idea of his prior knowledge and therefore no way of telling how much scaffolding will be needed. Experience taught me, though, to never ever make any estimates based on the initial mail. No matter how crystal clear and straight forward it may seem.

sorry face
Oh, I forgot to mention that. It's not going to be a problem, is it?
The premise is that the client doesn’t know what he is doing. So, he is going to flip flop around. He will come up with last minute “minor” change requests. He will ask an unexpected comprehension question, undoing everything after it was already tied up. In other words: clients tend to unwittingly turn laid out plans into piles of smoldering ashes in an instant, while being totally oblivious to the fact that this drives cost on my end.

Under such circumstances, charging by the hour for software development is futile. When freelancing, my price calculation always contains an error margin, large enough to cover for doing the preliminary work at least twice over. This is non-negotiable and it is also non-refundable.

It’s more than just writing code and the job’s not done when delivering the executable

Writing and compiling the code is the least time consuming part of the deal. It’s what comes afterwards where the hours are burned:

  • The client will probably want instructions on how to use his fork. That means writing documentation and/or walking him through. Usually, both. The later can turn into a nasty surprise in case I overestimated his technical skills.
  • Just because the mod works on my PC doesn’t mean it will work in the client’s system. More likely than not, there will be a remote debugging session (potentially with a client, whose technical skills I overestimated).
  • The main development branch will move on. The client may want/need the new version with his custom patch applied eventually. This means, I now have two code branches to maintain and should probably also write some extra unit tests to detect breaking changes.
  • After completion (and payment), there will likely be “minor” follow up questions. Things, that can be answered in one sentence. Individually, they take up almost no time at all, but they will pile up and are impossible to consolidate into billable units.

Again, counting hours is pointless. How long the job takes is largely determined by the client’s actions, not by mine. That’s a big variable beyond my control. The client can (and will!) drag this out, putting me into an impossible situation: I’m suppose to give a quote in order to get the commission, based on information, I can only have after finishing. But at that point, it’s too late to change the estimate and simply charging extra after giving a quote is obviously not going to fly.

A time based estimate is impossible when the known quantity gets swallowed by an unknown one.

Now, some people might wonder, why I don’t just write a detailed offer/bill then. Listing all the individual positions, so the client knows exactly what he’s paying for and why it’s costing so much. Am I too lazy? Yes, I am! I am mostly too lazy to argue about why every item is required, having to take it out because it isn’t, having to add it again because it was and in the end renegotiate everything because safety margins were not used to their fullest extent.

Everything that’s on an offer/bill is contestable. Haggling costs additional time and can’t end in my favour, no matter what. I learned the hard way to not put that option on the table.

Aren’t we forgetting something?

The basis for the commission is still an open source project. Yes, it is free to use, but it is not free to maintain and by creating it, I made an investment, indebting myself to myself. Now, why should some people have to pay, while other’s don’t? I could make an elaborate argument here about it being a mixed calculation and not being required to offer everyone the same deal, but I got a much simpler and more compelling one: if your business rides on the availability of a certain tool, then maybe it’s a good idea to keep the toolmaker in business.

Think ahead Software does not wear out, but it does get outdated.

Again, this is not up for discussion and the easiest way to avoid discussion is by not listing “funding the project” as a separate item on the offer/bill. If I were to charge by the hour, then this would be where my rate gets blown out of proportion.

It costs money to earn money!

At this point it should have become abundantly clear that I can’t exactly freelance on the quiet. By now, there’s enough money on the table for the taxman to take notice. In order to (legally) claim it, I’m forced to register a business. I’m not going to go into detail on the numerous ways of doing this, that’s a topic for an article of it’s own (more like a whole article series actually). The important thing to understand here is that besides being boss, I’m also:

Head of marketing
The hat of marketing - I wear it while writing blog posts

  • Head of software development
  • Head of operations
  • Head of marketing
  • Head of accounting
  • Head of legal

A client will see me wearing a lot of different hats (some funnier than others) during the course of our interactions. Each of them did cost money to acquire, some cost money to maintain and all cost time when used. Running a business means having operative costs and administrative overhead, regardless of whether or not I’m currently working on commissions. I got those hats in order to be able to interact with clients in the first place. So, everything the hats do is chargeable, even though just one of them is seen delivering the goods in the end.

Conclusion

Once you decide to take money for a service, you start walking down a road that requires you to build, maintain and pay for infrastructure. A client who doesn’t understand that simply is a client not worth having. Best not to waste any to time on him, by putting him off as early as possible and that, in a nutshell is why “it costs four figures”. Stop thinking like an employee, as a freelancer, you aren’t.

Thanks for reading!