Most of the issues that clients come to us with have to do with the nuances and weak spots of their contracts with customers.

After 7 years of work in the IT field, I’ve seen a lot of companies with contracts that they “borrowed from a friend”, “downloaded from the internet”, or “received from a customer who refused to make changes to it”. And it even worked, for a while at least.

Eventually though they would notice they were bleeding money, their customers would refuse to pay for their services, they had their hands tied by a non-compete provision, etc.

If you’re looking for better security for your company’s profits, here’s a brief checklist for signing contracts with your customers.

Step 1. Checking general contract terms

1. Subject of the contract.

Make sure this part is worded accurately and unambiguously. It should give a clear answer to the question, “what are we supposed to be making”. An app, a website, an update for an existing product, or something else.

2. Transferring rights to intellectual property (IP).

The safest option for an IT company here is to state in the contract that “non-property rights to IP are transferred to the customer after all payments under this contract have been settled”.

This provision has proved a lifesaver to a lot of our clients when their customers, for various reasons, were refusing to pay them.

3. IP clearance.

If the provision reads along the lines of, “The Contractor guarantees full clearance of intellectual property”, do your best to remove it from the contract.

What this means is, you pledge that whatever you create as part of the project will not infringe on anyone’s IP rights, worldwide.

To make good on this commitment, you’d need to conduct a global examination of every single part of your code. It’s a long and expensive process which still won’t be able to guarantee that someone out there won’t have made the same thing as you. Consequently, if that someone then takes issue with your customer regarding the rights to the code or product that you created, the one ultimately liable is going to be you.

4. Undisputed invoices as a settlement condition.

Do your best to get rid of this, otherwise it will allow your customers to withhold payment on the basis of a subjective (without specific, pre-agreed criteria) dissatisfaction with your work, for as long as they remain dissatisfied.

In practice, this means you’ll be making change after change to the code or product, wasting time and other resources at your own expense.

5. Non-recruitment clause.

This part should be included. If there isn’t one, ask to add it, and make the penalty for violating it sizable – about $50-100k. If the contract is merely going to state that poaching staff is not allowed, it’s not going to protect you.

Of course, the counterparty could refuse to include a clause with a penalty like that. In that case, it’s up to you to decide whether that customer is worth the risk of losing someone on your team.

6. Inordinate confidentiality requirements.

Consider your specific situation if a customer wishes to prohibit any mention of your cooperation in the future.

If it’s a regular project, such requirements are fine.

However, when you have an image-building, innovative and all sorts of impressive project, being associated with it could give your company a competitive edge. In this case, you should discuss this issue with your customer.

Maybe they simply gave you a standard contract and they actually won’t mind if you add the project to your portfolio. In any case, this is something worth discussing.

7. Non-compete clause.

Under no circumstances should it hamper the growth of your business.

Say, you’re known as a first class developer of FoodTech apps, and one of your customers wants you to stop working your niche for a year after your current project ends.

If this happens, the IT company’s management should consider all the pros and cons of such an agreement, assess potential pitfalls, and only then decide how to proceed: sign and abide by it, sign it with no intention to comply, or refuse to sign it and continue negotiations.

8. Force majeure.

If this clause isn’t specific enough, allowing customers to potentially neglect their commitments, it would adversely affect the security of your business.

Instead of something vague like “the COVID-19 pandemic will be considered force majeure”, the contract should state, “a situation when the Customer has suffered direct and non-recoverable losses as a result of the COVID-19 pandemic will be considered force majeure”. Repeat for every other circumstance as needed.

While at it, make sure that your team will be able to invoke force majeure for pushing back deadlines and for other circumstances.

9. Jurisdiction for resolving disputes.

It should be accessible to your company (both geographically and financially). This issue needs to be addressed on an individual basis, and under no circumstances should you ignore it.

Contracts often name some expensive jurisdiction, making it financially non-viable for the IT company to initiate legal proceedings there if they have a disagreement with a customer.

If you’d like to check your contracts or tailor them for new business goals, help is but a click away.

Step 2. Checking terms of different types of contracts

Mixing terms from different types of contracts, or using a wrong type of contract, brings IT companies all kinds of trouble.

When reading a contract of a certain type, you should know: 1) what should be in it, and 2) what definitely shouldn’t be there.

So make sure your specific type of contract contains the following:

Fixed Price:

  • detailed and unambiguous technical specification (if you see any vague point, ask to clear it up),
  • deadlines for acceptance of work (without those customers could take their time paying you, dealing with their own issues instead),
  • step-by-step description of the procedure for changing the TS,
  • statement allowing pushing back deadlines if your team was unable to work uninterrupted through the customer’s fault,
  • if you provide a warranty period for your services, it should be sensible (2-3 months, not several years).

Time & Material:

  • no quality requirements,
  • no clause making acceptance of work dependent on quality,
  • invoices are paid within a specific time period and without any extra conditions.

Dedicated Team:

  • same as Time & Material, plus
  • details on sick leave and and vacation pay for members of the dedicated team,
  • names of the dedicated team members,
  • procedure for replacing employees on the dedicated team,
  • maximum allowed number of such replacements.

Outstaff:

  • same as Dedicated Team, plus
  • details on selecting developers that will be working on the customer’s project (requirements for developers, deadlines, approval of candidates, etc.),
  • specific conditions that the company undertakes to create for the outstaff team,
  • organizational and technical management of the outstaff team is to be done by the customer.

How it works in real life

The above checklist contains ideal terms that will bring you the most benefits. It’s what any IT entrepreneur should aim towards.

Of course, life is too complicated for ideal terms, and we often have to sign contracts that are not that perfect.

However, armed with our checklist, you’ll know what terms are best for you and what you should try and put in the contract. So, when you find yourself having to make concessions, you’ll be aware of the risks and benefits involved, which would allow you to make an informed decision.If you want to ensure the success of your undertaking, we at Tretten Lawyers will be happy to go over your contract, or draw up a new one. Contact us here.