SHOULD SOFTWARE DEVELOPERS GET DOWN PAYMENTS?
I have always been of the opinion that developers should get a certain percentage of their payment upfront before the commencement of any software development project.
I had never thought that this was a conversation i would ever need to have because, as far as i know, it is a norm. However, recently, in a discussion with a prospective client, the issue of “to charge a down payment or not to charge” came up. I didn’t think this was something anybody would object to but this prospective client made some really strong arguments and was ready to hold very firmly to his views. His view was that an application is a product and he is paying for the product and not the service that go into developing the product and as such will pay only on delivery of the product. Well, I couldn’t buy that argument. I think that developers should charge a down-payment
WHY SHOULD DEVELOPERS GET A DOWN PAYMENT ?
A down-payment is a prepayment, security or a deposit for delivery of a service or purchase of something on credit. There are four good reasons why developers are expected to charge a percentage of cost to their client as a down payment. Some of these reasons are;
- Keeping both parties honest : Application development requires a lot of time and effort, so a down payment is a way of getting the client to stay committed to the project from inception till completion. A down payment makes it more difficult for a client to bail after development or renege on an agreement halfway through the development. It also make the developer stay motivated through the development lifecycle.
- Down payment keeps both parties motivated: In software development, especially custom development, there are certain inputs that are required from the client. Without a down payment, the client may be less motivated or lack the enthusiasm to provide the necessary input as at when required and this could stalled the development.
- Project related purchases: In the course of developing an application (web based or standalone) there is always a need to make certain project related purchases. To make these purchase will require a certain amount of money. Developers do not like to make these purchase off their pockets because they are sometimes not sure if the client will be keeping to their end of the bargain especially when there is no down payment.
- Down payment build trust between client and developer: Down payment speaks “trust”. Trust is needed in any business relationship. A client who makes a commitment and pays you a down payment is saying “I trust that you will do a good job on time and within budget”. Developers never want to let down a client that has put this trust and confidence in them and they ensure to keep their end of the bargain.
These are some benefits of charging a down payment . However, sometimes clients have their own question. What if this developer can’t deliver my specification? What if this developer lacks the expertise? What if the developer would not deliver at the scheduled time? Well, all of these “what if’s” can be answered by one simple answer. Get a good solid contract. Once you have this then you cover both your end and also cover the customer's fears. A solid contract is one that protects you as a developer and also protect the customer as a paying customer. Any developer who is reluctant to enter a contract that would protect the customer does not deserve to get any down payment.
My good solid opinion however is that developers and software companies deserve a down payment from clients and should do their best to get it. I can not say for a fact what percentage of the total fee should be paid up-front as this is relative to the project type, total cost, project related purchases, relationship with the client etc.
If you have an alternative or similar opinion, I will be happy to hear your view in the comment section.
From a non techie, I'd say value lies in the eyes of the client: A lot of work may have gone into getting a product built, but as a client, I'm really after the end product and not the process by which that product is built.. Unless the process can add some kind of value to my business. The case for keeping parties motivated is an issue a good contract can assuage.
Obi O. Thanks for your comment Obi. I agree with you on that. However at the start of the process you have no shipable product and will depend on the customer to make an upfront payment to begin the development process. There lies the problem - being able to get the customer to make a commitment to the development process without any single code being written. Hence I think that's where a contract will help both parties and maybe references from past projects.
I think I agree/disagree slightly with both you and your client who wants to only pay on delivery. Software delivery is a process and in a proper agile process, the development team should start to produce deliverables quickly and adapt to the customers usually changing needs. In such a situation, it is transparency that brings trust. As long as the development team is able to build incrementally shippable software, then the customer would be able to pay for a delivered product commensurate with what has been delivered, while the developer/team gets to start taking home some form of financial commitment very early on in the process rather than at the end. So if you were to invoice after your sprint retrospective for instance, you would have had the chance to show the client how you have created value and indeed how they can start to utilise your software in order to receive ROI. I find that the clients are often them more willing to pay a little bit more in the long run because they start to receive value early on rather than at the end of the project.
Thanks for your comment Martin Mbonu. I agree with you as regards the project lifecycle of software development.
I might not totally agree with the 4 points, but I still agree that developers be given a down payment. The reason is because its a service you are offering, to help develop that product. Remember that software development has a project life cycle? from requirement gathering all the way to support.