I’ve been working on starting a software collective, and spend a nontrivial amount of time doing non-technical things (namely discussions with clients and reading contracts). Here are some of the key points I’ve found so far, and what feels intuitive. They’re yet to be tested longer term, but I plan to update this post as I gain more experience. I wouldn’t go off and use this as a template yet (although it is what I use), but as a reference to learn what usually makes up a contract and where some gotchas might be.

I’ll throw in the usual IANAL (I Am Not A Lawyer) disclaimer. Contracts are quite important, but most of us are stuck deciphering templates people use on the internet, and the alternative is talking to a lawyer @ $1000/hr.

To be honest, I don’t know what I’m doing. There are differences that matter between what software service is offered (web, mobile, ML, and blockchain contracts).

Table of Contents

Client-contractor/consultant relations are king

Ideally, contracts should be a formality. A client has a need, and a software person can fulfill that need. Expectations should be set on a verbal level, and the contract helps protects both parties with more explicit terms. By trying to think ahead, some uncertainty gets taken care of. The goal should be that nothing escalates beyond whats in the contract. Unfortunately, no contract is going to be complete, therefore there needs to be some clause for arbitration. Getting into enforcing terms and disambiguating expectation inconsistencies is time-consuming, expensive, and probaby what nobody wants. That said, not everyone wants to play fair, and here are some things to watch out for.

Deliverables and timelines

Start with specifying exactly (either verbally agreed upon or explicitly here) what you are doing for the client, by what dates. I usually like to put deliverables in two week phases, and manage uncertainty.

Warranty and Support

With the deliverables explicitly and verbally agreed upon, it makes sense to provide some warranty for previously agreed upon terms. Usually giving a period for free, and then charging for longer term maintenance makes sense.

Part of this warranty is also specifying exactly what platforms (OS, browsers, etc) are supported.

Unfortunately thinking on this more, there may be need of a “customer support” function here.

Support

Support is a little different from the warranty. It goes into the territory of adding more features. If there are predictable and atomic features to support, it may be beneficial to include these in the contract.

Payment Schedule and Late fees

In the same way the deliverables are detailed, specify when and how much it will cost. Note whether you have an internal hourly rate, or charge by project. If your deliverables are in phases, note how the billing schedule will be.

Add a clause about how long when invoiced payment is expected, and whether you reserve the right to charge late fees.

Intellectual Property (IP) & Rights to Work

It’s important to talk about who owns the rights to the work. In software, IP enforceability is a different animal, but for the long term you want to do things by the book. Discuss what your clients needs are. Are they a startup? Maybe they need an exclusive license or all the rights to the work. Do they just want a problem solved and nothing else? Offer them a non-exclusive license.

From my reading on the internet, we have:

• All rights to work
• Exclusive license
  • In practice, looks to be the same as “All rights to work”
• Non-exclusive license
• Duration of the license
• Royalties

Terms

The rest of these terms are more boilerplate, but I’ll walk through each of them.

• Reservation of Rights
  • Any rights not mentioned in this contract are given to the developer, and must be negotiated separately.
• Independent Contractor Status
  • For tax and legal reasons, you establish yourself as a non-employee independent contractor
• Cancellation
  • How do you charge/who owns what if the client cancels?
• Indemnification
  • Not holding the consultant/developer from any damages incurred by a third party (e.g. client gives software to the users, who suffer damages)
• Arbitration clause
  • How will you resolve disputes?
• Assignability
  • Not allowing either side of the contract to be assignable (A.K.A who’s on the hook for being the client, and the developer)

Notes

• At some point I may want to make a video about this, and decipher some of the contracts.
• How do they differ from contracts in other industries (sports, modeling, show-biz)?
• Some example contracts?