Note: the payment structures described in this article are most suitable for smaller projects (e.g. around a month in duration).
How much deposit should you take before starting a project? When should you ask for interim payments, and how much should those installments be? These are pertinent questions for anyone involved in software development contracting.
For those that want the short version, what I use is this structure: 20% deposit, a 70% interim payment when most of the work is done, and a final 10% payment on project completion. Unfortunately, this structure does have a flaw, but also a major protection that other structures don’t have.
Let’s take a closer look at some approaches for dividing up payments during a project’s life-span.
Method I, 20/70/10 – although not perfect, it’s the best system I’ve used so far. Let’s break it down and show an example:
20% deposit → before work begins
70% interim payment → when most of the work is done
10% final payment → when the project finishes (i.e. sign-off).
Example project, total budget: $ 5,000
Payment 1: $ 1,000
Payment 2: $ 3,500
Payment 3: $ 500
When do you send out the 70% invoice? I send out this invoice when my production checklist shows that 90% of all tasks have been completed.
The beauty of this structure is in the 10% final payment. This drastically alleviates the unfair penalty contractors suffer when a client ‘drags their heels’. One of the most common causes of this situation is when a client fails to provide content in a timely manner. This can also happen when a client decides to put their technology project on-hold in order to focus on another area of their business.
The biggest pitfall with this method is the large interim payment. Having to find such a big chunk of cash all of a sudden for a small business can be quite daunting.
Method II, 20/80 – there was a time years ago when I used this structure. An initial 20% deposit before the project started, then when the project finished, I got paid the rest of the money. Unfortunately, this method is fraught with peril.
For example, if a project has a budget of $ 5,000, suddenly asking a small business owner for $ 4,000 at the end of the project is just asking for trouble. There could also be serious cash-flow consequences for a contractor should a client decide to delay completion of their project.
Method III, 50/50 – I have worked at a company that used this structure. This doesn’t really need much by way of explanation; its just 50% up-front and 50% on project completion. The biggest advantage of this structure is the large up-front cash-injection it offers. This can be important for a small company which employs a handful of staff. However, there is also a major drawback. If the project drags on for any reason, a large portion of the budget gets locked in limbo.
Method IV, 20/75/5 – this is obviously very similar to method I. This is the structure used by a web development agency I worked for a few years back. It’s where I was first introduced to the notion of a small final payment as a contingency against stalled projects.
Method V, 25/50/25 – this percentage carve-up was suggested to me by one of my peers. This is quite a good structure in my opinion, the amount being asked for as a deposit is reasonable, the interim payment would appear less daunting to the client when it becomes due, and the final payment even if ‘held to ransom’ isn’t a massive portion of the project’s budget.
Method VI, 35/35/30 – another freelance contractor I consulted with described this structure. This particular method is interesting because of the points at which the installments are charged:
35% deposit → consultation, planning, design
35% interim payment → construction of prototype
30% final payment → completion
This approach takes some explaining. Because the client can hold off nearly 1/3 of the project’s value until completion, they can budget more effectively and also retain leverage to ensure satisfaction with the project.
The large deposit is obviously a boon for a freelance contractor in terms of cash-flow. However, the client does have the option of dropping out of the project at the second payment point and taking the prototype. Even if the client did decide to take the prototype as the final deliverable, the developer still gets 70% of the project’s total budget.
One of the great things about this method is that at no point is the client being hit with a massive invoice.
Method VII, 33/33/33 – this approach is used by another freelancer I consulted with. They mentioned that the last 33% usually balloons due to scope-creep. So in effect, the first two payments are of equal proportion, but the last one is commonly larger because of feature additions.
Method VIII, 80/20 – this unique structure was described to me by a freelance contractor. This developer collects 80% of the project’s value by the time the project is complete, via multiple installments along the way. The remaining 20% is charged two months after delivery; if the customer is satisfied. If the client is not satisfied, they are required to write up a half page reasoning to justify themselves. It is at the client’s discretion if they don’t want to pay that remaining 20% if they aren’t happy.
20% of a project’s budget can be a significant amount of money to lose should a client decide they aren’t happy with the end product. Nevertheless, this can be an effective strategy when developing a relationship with a new client. In affect, you are asking a new client to trust you when they don’t know you. So this acts as a statement of commitment to not only complete the project, but to complete it to the client’s satisfaction. Obviously, this does expose the developer to being taken advantage of by unscrupulous clients, but then again, you would know quickly not to work with that client in future.
By no means is this an exhaustive list of payment options, but hopefully it does give you some perspective on what others out there are doing.
You may notice a common theme with all these structures; they are generally in three stages (i.e. deposit, interim payment, final payment). The reason for this is because generating more then three invoices for a one month long project is overly bureaucratic. It also results in an unnecessary level of administrative overhead.
This discussion wouldn’t be complete without a quick word on the importance of deposits. Any savvy businessman will tell you to get a deposit before starting work, but not everybody does this. As a general rule, always get a deposit before the project starts in earnest. There are circumstances in which I will start work on a project before I’ve taken a deposit, but I will only do a few hours of work before stopping and waiting for the deposit to arrive. If it’s a new client, I won’t start any work at all until the deposit arrives, if it’s a long standing client with a good history of paying their bills on time, then I would happily start work on their project before their deposit arrives.
Louis Marshall, Project Manager
My tech blog: pm4web.blogspot.com