How to Charge for Programming

by Mark Shead on February 11, 2011

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.

About 

{ 7 comments… read them below or add one }

Anon ymous February 12, 2011 at 6:02 am

How do you deal with clients who insist on confidentiality? eg. signing NDAs … wanting to keep trade secrets … preventing you from using ideas you’ve developed for them in other projects?

Reply

Mark Shead February 12, 2011 at 10:59 am

If they think every idea they have is brand new and needs and NDA, it is probably a good indication that they are going to be a lot of trouble to work with.

Reasonable NDAs might be something along the lines of: “We have an algorithm that we use to predict which one of our customers might double their order if we call them, but we can’t share it with anyone unless they sign an NDA.”

Reply

Anon ymous February 15, 2011 at 9:56 am

Thanks for replying Mark. I wanted to follow up on the trade secrets issue … preventing you from reusing a concept you’ve developed for them (under the client’s disclosure but using your skill & knowledge) in other projects. Where do you draw the line? … and any examples of such conflicts?

Reply

Mark Shead February 15, 2011 at 10:07 am

I know that some programmers basically tell their clients that they (the programmer) retains the rights to the code, libraries that are developed in the process of writing the code, etc. The client is simply given a perpetual unlimited license to use the code. That way the programmer can reuse anything they want for their next client. Obviously this type of approach would work well if your client is a hospital and is asking you to write code to hook their lab equipment to their electronic medical record software. It probably wouldn’t work if it is a startup with an idea for the next Twitter or something. The startup isn’t going to want you to have the right to just sell the software to a competitor.

What I usually do is retain control of the general libraries developed along the way. So if I’m working with a client that wants some type of e commerce functionality, I’ll break the credit card processing out into a separate library or module and include it in their product. Then I’ll use it next time I have a client that needs that type of credit card processing. However, I’m not going to just resell the product I made for them to someone else.

JMasciantoni February 15, 2011 at 9:42 am

Mark,
As a “silver back” developer I’ve had to deal with every one of these scenarios and you are right on the money for each one.
When one opts, hopefully in the rare occurrence, to partner then take the time to set up a quick limited liability partnership. Luckily these are easy to setup (and easy to dissolve) but worth their weight in gold if things go well.
I’ve found option #3 to work the best. However which ever method is used it is worth the time and effort of developing and keeping the best possible relationship with your client. Word can travel fast these days. Just ask Mubarak :-)

Reply

Oscar Martinez February 15, 2011 at 5:45 pm

This is perfect. I just started working as a freelancer in the evening and weekends, and I have this project I need to estimate. I’m going to follow your advice and estimate x first =)

Reply

jonaskinny August 10, 2012 at 2:00 pm

Absolutely on the mark … Mark. The partnership idea of a hybrid pay/equity is the most logical way to go where the developer needs to shoulder most of the risk upfront. If the non-developer partner(s) have captive clients, very unique (patent worthy) idea, big name etc. then a small living stipend with larger equity may make sense. But for the vast majority of cases (where there is the idea but not much else) 50% comp during active development, with equity remainder that bleeds off over time is my model. This way the non-developers get the ‘blue sky’ if it ever comes, the developer limits the downside to 50%, and could gain upside ( 3-400% perhaps) before their equity is gone. Otherwise you are essentially (at least partially) working for free.

Reply

Leave a Comment

Previous post:

Next post: