In his infamous “F*ck You. Pay Me.” talk, Mike Monteiro of Mule Design warns, if you hear the phrase “You can trust us,” walk away. While goodwill and mutual interest is the foundation of every successful partnership, a contract is fundamental to any professional relationship.
Whether you are a freelance developer, or an engineering manager hiring one, you should protect your interests with legal assurances in the form of a bilateral contract outlining the Terms of Service.
By defining expectations, responsibilities, scope, review and approval of work, a contract helps to keep an engagement on track to completion and ensures both parties have their conditions met.
In this article, we will explain the vital considerations and clauses that should be in this legal document to best protect both parties working on software development projects, as well as common mistakes to avoid. Freelance contract templates and services are also suggested.
Both parties should keep in mind that contracts are negotiable until signed. Neither party is obligated to blindly accept the other’s terms. A bilateral contract should protect the interests of both parties, and it's perfectly acceptable to ask for revisions, changes, and additions. When negotiating a new contract,it’s best to be flexible and consider the needs of your potential partner, but for the items most important to you, stay firm.
Many freelance developers will not offer concessions on payment terms, liability, or clauses that guard against scope creep (ever expanding project requirements). Entrepreneurs, on the other hand, should be sure to include their desired language on confidentiality, intellectual property, and transfer of rights.
Either party may provide the contract, or, when using a talent matching platform like CodmentorX, the platform will most likely have this documentation already prepared. Regardless of where the paperwork comes from, you should be knowledgeable about what’s in it and the legal protections available to you.
Every partnership and software project project is unique, and the contracts that govern them should be too, but core clauses and protections will remain in place. Here’s what’s most important to have in freelance development contracts.
Expectations and responsibilities ensures that all parties are clear on what role they should play, how they should cooperate, and what the expected result of the engagement is. The client should detail the goals, scope, and requirements of the engagement. They should also provide any information, resources, and capital that will be required to reach those goals.
Expectations and responsibilities also need to define the service to be rendered. For example:
The developer will write a content managing system (back-end logic and front-end UI) using Ruby on Rails. The developer is not responsible for inputting images, or text. The developer will perform unit and integration testing, as well as front-end testing for the latest versions of desktop browsers Safari, Chrome, and Firefox. The system will not be written for mobile browsers, and there will be no mobile testing.
Notice that the service to be performed clause also detailed what the developer was not responsible for. It’s important for the freelancer to specify the limit of their responsibility so that client-contractor expectations are aligned uncompensated work is avoided.
Specific requirements may be more detailed in a document that accompanies the terms of service contract, often known as a statement of work. If drafted by the freelancer, it is referred to as a project proposal. This document should also define what will be considered a work product, the tangible and intangible results of the service provided by the developer. Defining the work product helps to make the goals and scope of the software project explicit.
The independent contractor clause is important to avoid undesired taxation. Without establishing the independent nature of the service exchange, the client will have to pay employee taxes, and the developer will not be able to deduct business expenses as a sole proprietor. The standard independent contractor clause looks something like this:
Each Party shall act solely as an independent contractor, and nothing in this Agreement shall be construed to give either Party the power or authority to act for, bind, or commit the other Party in any way. Nothing herein shall be construed to create the relationship of partners, principal and agent, or joint-venture partners between the Parties.
A regular work report is the primary means for communication and feedback between developer and client, and is especially important when the the client is contracting a remote developer. To ensure smooth progress on the project, it is best to lay out exactly how the work report will be coordinated.
Depending on the needs and velocity of your software project, various time increments may be set for work reports to be submitted, though weekly work reports are common. For the given period, the developer should inform the client of the tasks completed and the results. The client will then have a certain number of days to review and approve or disapprove the work report. The report can also detail what tasks are up next in the pipeline, and any questions or issues encountered on current tasks.
The more specific the better. You can designate dates or days of the week for reports to be submitted, reviewed, and returned. Additionally, the contract should name the individual that will be responsible for receiving and reviewing the work report. It’s best to avoid multiple points of contact, which can result in more back and forths, delays, and conflicting feedback.
A work report ensures that everyone is on the same page as the project moves forward and errors are caught early, before they can snowball and derail a project.
Write clear payment terms in your contract to help avoid any potential confusion or compensation delays, which can stall your project and sour relations with your developer. Whether you use fixed cost, hourly, or retainer based payment, the amount will be derived from the hourly estimate or the actual hours worked.
Like everything else in your contract, payment terms should be specific. Here’s what to include:
Though clients may not be so keen to sign on for punitive measures like late fees, or picking up the tab for bank service fees, it is standard for the purchaser of services to absorb these costs. Freelance developers cannot be expected to incur extra costs of doing business, and are not likely to offer their services to clients who insist that they do.
Project goals or deliverables are also relevant to payment terms. If these are not well defined, freelancers may request a clause to stipulate that if project scope should significantly change, payment terms may be renegotiated. In some cases, the entire contract may be renegotiated to reflect the new goals and scope.
Confidentiality and transfer of intellectual property rights will most likely be covered in greater detail in a separate Non-Disclosure Agreement(NDA), but there is still a place for this in your Terms of Service contract. Entrepreneurs want to ensure that they will have ownership of the work produced resulting from the engagement. They also need to protect the trade-secrets that comprise their business advantage, which should be labeled as “confidential” in the non-disclosure agreement. Both the NDA and the primary Terms of Service contract may declare the following:
Confidential information shared with the receiving party shall remain the exclusive property of the disclosing party.
Confidential information may not include public knowledge, prior knowledge, knowledge developed independently, or third party knowledge.
The confidentiality and intellectual property rights clauses may stipulate that full ownership of rights will only be transferred upon payment in full. We can all agree that payment for work completed is a fair way of doing business. The clause may be worded like this:
Upon full payment for time and work completed, all ownership and use rights will be transferred to Party B.
The termination clause should designate an expiration date at which the contract will automatically terminate. It should also spell out what will happen in the event of a premature termination.
The first (and most ideal) situation is natural termination. The contract, for example, may expire after six months, with an option to renew.
In case things get sticky, the contract should have provisions for early termination. Possible reasons for premature termination include breach of contract, nonpayment, or changing business circumstances (which could mean pretty much anything).
Since things don’t always go as planned, many freelance developer contracts include a provision that “either party may terminate the agreement with reasonable notice (e.g., 30 days)”. To protect the freelance developer from significant loss of income or opportunity costs, there will often be a "kill fee".
The kill fee provision may include the following:
In other cases, the kill fee may just be payment for hours completed to date (less favorable for the freelancer).
Note, the kill fee should not be seen as punishment — it is mostly to protect the freelancer for fixed cost projects, in which case he or she risks getting nothing if the project is terminated.
Liability cuts both ways, and both parties should be protected from unreasonable legal claims and financial responsibilities. To protect the freelancer, the clause should have language to relieve the service provider of any responsibility for damages due to future malfunction of the software. Here is an example adapted from Docracy:
It is not possible to guarantee that code will function as intended indefinitely, so Party A cannot be liable to you or any third party for damages, including lost profits, lost savings, or other incidental, consequential or special damages, even if Party B has advised of the possibility of such damages.
The freelancer should also be protected from third-party IP infringement claims — if during production the client provided information it had no right to use, the freelancer should not be held responsible.
Party B guarantees that any elements of text, graphics, photos, designs, trademarks, code, or other artwork provided, are either owned by Party B, or Party B has permission to use them.
By the same token, the client should be protected from any excessive damage claims that the freelancer attributes to the engagement. Here’s an example from Contract Killer:
Your liability to us will also be limited to the amount of fees payable under this contract and you won’t be liable to us or any third-party for damages, including lost profits, lost savings or other incidental, consequential or special damages, even if we’ve advised you of them.
If you have a truly mutually agreeable, bilateral contract, most likely you won’t need to worry about severability….unless a legal battle ensues, which is why you should still have it in there. The severability clause holds that “should any clause of the contract be found to be illegal, unenforceable, or invalid, the rest of the contract will remain valid”.
Should things go awry, mediation, followed by arbitration, should be the preferred methods of dispute resolution. Mediation is basically a moderated discussion to address disagreements and explore solutions.
Arbitration is more formal, resembling a mock trial, and is held in an arbitration committee. Depending on the language in your contract, arbitration committees can deliver binding or non-binding decisions, which are often a strong indicator of what the results of actual litigation might be. Opting for binding arbitration ensures that costly litigation will be avoided, while non-binding arbitration leaves the door open for formal legal recourse.
The contract should designate a specific county and arbitration committee to oversee the dispute resolution.
Lastly, your contract needs to identify the territory whose laws will be used to govern the contract. By specifying a legal system, you ensure you have more than just a piece of paper — but a legally binding document supported by laws. Additionally, if either party really wants to spend exorbitant fees on litigation to resolve disputes, the Governing Law clause tells them which court system to turn to.
To save you time and money, you may want to reference some freelance contract templates or use a service to help you customize your own contract. Here are a few to get you started.
Once the contract is signed, both parties are bound by it and are required to stick to the agreed upon terms until termination or a renegotiation of terms. If you are establishing a partnership with a remote developer, you’ll have to navigate contracts digitally. Luckily, there are a plethora of document management tools to make this easy for you. Here are some of the most popular ones:
Now that we know what should be in a contract, what shouldn’t be in it? Well, lots of things, but here are a few more common red flags that you should strike, or walk away from.
A freelancer’s compensation typically should not be dependent on a client’s subjective satisfaction. The terms of the contract outlining project scope, responsibilities, expectations, and work approval will be enough for the client to hold the freelance developer responsible for the quality of work delivered.
Changes and adjustments
Look out for any clause that requires the service provider to make excessive changes. It may look something like this: “the contractor will make any adjustments and changes as instructed by Party B...” This is a recipe for scope creep. As discussed in the payment section, any change in goals or requirements should entail renegotiation of compensation, or even the entire contract.
An indemnification clause is the opposite of liability protection. It requires one party to compensate the other for future losses or expenses from third-party lawsuits claims. Plain and simple, you don’t want this in your contract unless the indemnification is on your behalf.
An exclusivity clause is arguably inappropriate for most freelance contracts. The freelancer should not be required to enter into an exclusive relationship with only one client and turn down other jobs. After all, they are freelancers, not employees. This can, however, be distinguished from non-compete clauses. It is acceptable for clients to ask that freelancers not accept software projects with entities that are in direct competition with them.
A freelance developer providing programming services to a client is usually a work-for-hire relationship. Therefore, any language that suggests the contractor retains all rights and licenses of the resulting work should be avoided.
For the best chances of a successful engagement, Mike Monteiro offers three tips for establishing successful business partnerships:
(1) Contracts up front — don’t supply information and don’t start work without one.
(2) Make internal allies — contracts are great, and they’re that much better if you know and like the people behind them.
(3) Work with advisors/lawyers — it’s standard practice to have a legal professional review your legal documents.
You will get the most value out of your engagement by starting with clarity, expressed in terms agreeable to all parties to the contract. Worthy clients know how to execute projects successfully and offer fair contract terms. Skilled developers expect nothing less.