How to Charge for Programming

Charging for programming can be a bit tricky.  Clients obviously would prefer a solid quote. However, any experienced programmer knows that what the client wants is going to change as the software takes shape. Furthermore, any non-trivial program is going to involve some unknown problems that the programmer may be able to solve quickly, but might take a long time. It isn’t easy to estimate how long it will take to find an algorithm that does X in Y seconds.

In order to feel safe giving a firm quote, a programmer is going to have to pad the numbers quite a bit to deal with unknowns, client changes, etc.  Of course this might push the price up to the point where the client decides it isn’t worth it.

An experienced client is going to have already experienced a project where they paid lots of money just working off of an estimate only to end up with software that doesn’t work and a code base that no one else is willing to touch. They can either keep sinking money into the project or just write off the whole thing as a failure.

So how can you compromise between what the client and the programmer both need?

1. Small bites

If you can determine the smallest amount of functionality for the software to be useful to the client, do that as an independent project first.  Instead of trying to quote for an entire year long programming job, pick the part that solves the most number of issues with the least amount of work and try to have something delivered in 2 to 4 weeks or less.

The client likes this approach because you are delivering solutions to problems instead of just a program. If they can get their biggest problems solved early on with the least amount of expense, so much the better. They may want you to do x, y an z, but if x gives them 90% of the benefits, you should definitely do that as a project and then let them decide if they want to proceed with y and z.

What you learn in completing the first project will make your estimate of the next project much more accurate. The chances of you getting anywhere near an accurate estimate when estimating x, y and z all together are very low.  The chances of you being able to accurately estimate y after having completed x are much greater.

You as the programmer face a lot less risk with a 2 to 4 week project as long as the requirements are defined and the scope is clear to both parties.  Keep in mind you need to clearly articulate not only what the software will do, but also what it will not do. Make sure the client knows what is being left out and what will be part of future projects should they choose to proceed.

2. Range estimate with upper limit

The client doesn’t want to pay twice as much just because you won’t know how long the project will take until you are half way done.  If you give a single quote that factors in the risk, they may feel they are being taken advantage of.  On the other hand, you don’t want to give a low bid only to find you drastically underestimated how difficult it would be to solve particular problems, interface with their existing system, etc.

Giving an estimate such as $5,000 to $10,000 with a cap of $10,000 is often a fair way to handle the needs of both sides. The greater the unknown risks, the wider the gap between the first and second number.  Basically the second number is the amount you’d want if you were giving a hard quote.  It should factor in all the risks of dealing with unknowns, the chance that the customer will change their mind a lot, etc.  The first number should be a reasonable estimate if everything goes ok with only a few minor problems.

The client will need to commit to paying up to the higher number.  If the project is worth it to them at $5,000, but not at $10,000 then you need to reduce the scope until the value and your upper limit match.

3. Charging for programming time

Some people like charging a low rate, but charging for every minute they spend on the project. They operate with the idea that, “If I’m doing something I wouldn’t be doing on my own, the clock is running.” This seems reasonable from the programmer’s standpoint.  However, imagine you are personally hiring a graphic designer to create some designs in HTML 5. The designer is good, but has mainly done work in HTML 4.  As a result they are going to be spending at least some of their time learning exactly how to use HTML 5. Do you want to be paying for their learning curve? Probably not.

Chances are very high that not all of your time on a programming project are going to be spent actually coding.  You’ll probably spend time doing the following:

• Reading the documentation for your framework
• Looking for open source libraries that will do what you need
• Looking through mailing lists archives to see how other people solved similar problems.
• etc.

These all might sound like reasonable things to charge for, but they are investments in making you a better programmer. My preference is to charge a much higher rate as an expert, but not bill for learning anything new.

I use a time tracking tool (Mylyn and TaskTop) that measures how long I spend working on a particular issue in my IDE.  That way I’m only measuring the time spend coding and not any of the time I spend doing research. The tool I use, times out after three minutes.  So if I just need to jump over to lookup the specifics of an API call, all the time is counted.  However, if I head off on a 30 minute search for a better open source expression language to embed in my program, it isn’t.

There are three consequences of this type of billing:

• The hourly rate I charge is much higher than some of my peers.
• 20 to 30 billable programming hours is a full week.
• My estimates are much more accurate because I’m only estimating actual coding time.

4. Getting paid

With known and trusted clients, I bill at the end of the month for any work performed during that month.  With unknown clients, I prefer that they pay ahead of time.  When my work depletes their deposit, they need to deposit some more money.

5. Partnerships

The world is full of people with no programming skills who are trying to invent the next Facebook and feel that the only thing holding them back is the fact that they can’t afford a programmer willing to work for a percentage of the company. You want to avoid people like that.  Ideas are cheap and generally you don’t want to ever partner with someone who is wanting you to bring the man hours and they will bring the “ideas”.

However, there are people that have something significant to offer that you can’t get easily on your own.  In particular this comes in the form of marketing and existing customers. The hard part of making money from selling software isn’t writing the software–it is getting noticed.  Partnerships with people who can help your product get noticed can be valuable.

You want to avoid partnerships where you front all the risk though. Your partner needs to have some type of incentive to use their connections, mailing list, clout or whatever to promote the product once it is ready to go.  One easy way to do this is to split the development cost.  You approach things the same way you do with a client, but you and your partner are both responsible for half the bill.  If you are operating as a sole proprietor, then you simply don’t pay your half of the bill.  If you have a corporation you may pay your half personally.

This type of arrangement means you both have something invested.  You have your time and they have their money–albiet a lot less money than they would have if they were to have tried to do it on their own.

If you deliver the software, but your partner turns out to be incapable of actually marketing it, you still have half of what you’d normally bill.

Partnerships are tricky and you need to be very clear and very careful how you set things up, so make sure you do your homework.  The main point here is to not overlook partnerships when the partner has something genuine to offer–and very rarely is that going to be their idea.