Secrets from the Industry - Avoid these things in your contract with your consultants

Over many years in the business software consulting space, we have seen contracts of all shapes, sizes, and various legal language. Some contracts are more predatory than others. We want you to avoid common mistakes we have seen when signing a contract with a software consultant.

1. IP Ownership

I want to draw a comparison to other industries. Say you are building your dream house. You will have to hire many different tradesmen—an architect, a builder, a plumber, an electrician, etc. You pay for the entire cost of building your dream house. After the house is built, you discover that you don't actually own your house. The rights to your dream house are actually owned by your architect, and you now have legal difficulty making any modifications to the home that you funded. That is absurd, right? Then why is it okay for software consultants to own the intellectual property of anything they build for you, that you are paying for?

Some contracts with consultants will claim IP ownership. This poses some issues, such as misalignment with who is actually funding the work, vendor lock-in, and reduced strategic flexibility.
‍

Some issues we have seen arise: If the consultant owns the IP, the client may be unable to:

• Hire another firm to continue development

• Fix bugs without the original consultant

• Integrate deeply with other systems

Even with a license, there are often restrictions on:

• Modification

• Redistribution

• Use beyond a specific scope
‍

Takeaway: If a consultant wants to own the IP for anything they are building that you are PAYING for, redline that language—or better yet, look for a different partner.

2. Fixed Constraints Around Automation

One of the silliest restrictions we see in statements of work is specific language on how many pieces of automation can be built.

Here is a Salesforce example: In some SOWs, you will find language such as "maximum of 5 flows, maximum of 2 Apex triggers" and other similar restrictions. This language is completely unnecessary and incentivizes the wrong behavior for a partner.

If you are limited to 5 flows, what if you have some business automation that has a higher level of complexity? Maybe there are many types of data checks, decisions that need to run, different database updates. With such an arbitrary limit on the number of flows, the partner is faced with two options.
‍

Option 1: Build a giant monolithic flow with hundreds of nodes, very difficult to understand and maintain, just to stay within the constraints of the contract.

Option 2: Ask for a change order to adjust the language, and with that change order, maybe even ask for more hours and more money to create additional flows/subflows to chunk the logic into smaller pieces.
‍

Takeaway: Keep an eye out for any arbitrary limits for how a solution can be built. These either promote bad architectural designs or cause unnecessary change orders.

Final Thoughts

Don't be afraid to go back to a partner with adjustments to any contract proposals they send you. You can learn a lot about the integrity of a consulting firm, and how they incentivize themselves, by looking for any of these types of contract clauses. Redline them, have the partner build a contract with your business outcomes in mind—or better yet, look for another partner.