Brett Miller is the president of Custom Software by Preston (CSP). For more than 10 years, CSP has impressed clients with highly effective software solutions and teams of multi-talented software engineers.
A software development client should complete a thorough “due diligence” before selecting a developer for his critical project. Then, he must complete the finalization process by drafting and executing the legal contract/agreement.
Contracts attempt to define the responsibilities and duties of each party; however, people often overlook whether a contract covers certain risks associated with non-performance.
Take a look at the eight scenarios below. These tips can help your company cover its legal bases when contracting a software developer, or vice versa.
1. Time & Material (T&M) or Fixed-Price Contracts
In a “time and materials” contract, the client assumes the burden of cost overruns, whereas in a “fixed-price” scenario, the developer assumes this risk. Weighing the two, many clients assume they are ahead of the game by passing the potential for cost overruns to the developer. However, they but fail to consider that the developer must add that cost-potential into their fixed-bid up front. So in a fixed-price contract, the client pays the extra cost, even if it proves to be unnecessary.
Fixed-price contracts also have the potential to create disputes. Often, deliverables that were implicitly intended might not be included in the original project scope. Both parties should be very aware of what exactly is included in the project. Fixed-price means there is a fixed scope of work, unless additional moneys are paid.
In a time and materials contract, the developer gets paid on an hourly basis. The motivation to finish quickly may be diminished by the opportunity to bill more hours. In this case, the client takes the risk that the developer will prioritize his own desire to profit on the project.
2. General Note on Contracts and Non-Disclosures (NDAs)
Contracts and NDAs are legal instruments which establish the rights, duties and privileges of those who are a party to the agreement. These instruments protect both parties to the extent that they are willing to pursue them in a court of law.
Here is a simple rule of thumb, although I encourage you to also check with legal counsel. Unless the dispute is over $10,000, most attorneys won’t take the case. And even if they do, they usually keep one-third of any money they collect. It can take several years to win in court, and the problem is further exacerbated by the fact that the losing party may no longer be in business or have assets from which to pay. One last note, many contracts call for the losing party to pay the legal costs for the winning party, which can save you money if you win, but cost dearly if you don’t.
3. Advanced Payment – The Industry Standard
Many contracts call for advanced payments or retainers. Essentially that means the developer works on the client’s money, and therefore, the client bears the risk for the developer’s potential lack of performance. This is the norm in the information technology field. Very few developers will take money out of their own pockets to build a client projects (in the hopes that the client will pay).
An improvement to this model would be to limit the retainer to two week’s worth (or less) of development time/labor (weighing the progress of deliverables). Upon client acceptance, the retainer can be replenished for the next cycle. Sending a wire or paying via credit card allows for instantaneous payment. Client risk is bit more limited when using this approach.
4. Phased Payments – The Other Industry Standard
Some projects are divided into three or more segments. The first phase is paid up-front (client risk); the second is paid at some pre-arranged interval (equal risk); and the last payment is made upon project “completion and acceptance” (developer’s risk). In this scenario the last payment can be problematic to collect, as subjective issues can arise regarding quality and scope.
One minor modification to the phased payment method specifies that the developer finish the final deliverable in their own environment, to which the client has access for testing. Upon client acceptance, the final payment is made and the vendor transfers ownership of the application and all code to the client. This is a very solid, technique balancing risk.
5. Warning! Warning! Kill Switches
Some unscrupulous software vendors build a kill switch into their applications. In the event of a dispute (and the client refuses to pay), the vendor can remotely shut down the application. I recommend that your contract include language that prohibits this “extortion like” practice.
6. Disappearing Freelancers
Many IT Professionals have heard this story before: A company finds what appears to be a knowledgeable (and affordable) freelancer on the Internet. Initial contacts with the individual indicate great responsiveness. Payment is made, a few conversations take place, some small progress is shown — then all communication goes dark and the freelancer disappears.
I believe this most often occurs when, with the best of intentions, a freelancer takes on a project and finds out he bit off more than he could chew. He believe his efforts were substantial, but things just didn’t work out (in other words, “not their fault”). Even more important, as a freelancer he is simply not in a position to refund any money. It’s easier to disappear than to deal with the conflict, so he runs.
Freelance software developers do offer expertise, experience and cheaper rates due to lower overhead, but the clear risk is a lack of any substantial backing. Therefore, this model does have more risk for the end client.
7. Payment via PayPal or Credit Card Carriers
Many developers accept payment via PayPal, and some even accept credit cards. These credit carriers offer “dispute” mechanisms that allow the payee to challenge any charge which was not delivered as promised or described. This method should be encouraged by the client (even if they need to pay the credit card processing fees), as it provides additional protection.
Vendors have an opportunity to respond to any dispute. Carriers to a certain degree are arbitrators and if they receive enough complaints, a vendor’s account can be canceled.
8. Risk Assessment
Software development projects carry financial risk factors for both parties. These risk factors need to be considered seriously and should be discussed with an attorney. Clients and developers alike need to know what they are getting into and prepare for scenarios that don’t work out as planned.
Image courtesy of iStockphoto, OtmarW, Flickr, quaziefoto, slimmer_jimmer
More About: contracts, contributor, dev, features, freelance, law, legal, software development, Web Development
For more Dev & Design coverage:
- Follow Mashable Dev & Design on Twitter
- Become a Fan on Facebook
- Subscribe to the Dev & Design channel
- Download our free apps for Android, Mac, iPhone and iPad
