SaaS Tips by Sapna | Tip No. 12 – Proof of Concept

If your SaaS system is going to be tested in a proof of concept (POC), be sure to put an agreement in place. A proof of concept (or POC) is an exercise in which you test the SaaS system to determine if it will work for your use case. Before engaging a new SaaS system into your company, you will almost always start with a POC.

The POC agreement would ideally restrict access to the SaaS in a test environment, disclaim any warranties and indemnities and require your customer to ensure that no confidential or personal data is processed while in the POC mode.

Do you need a SaaS agreement if you are using it for a proof of concept?

Some characteristics of a POC are:

  • The POC is almost always run in a “sandbox” or test environment. Since you are still testing, you wouldn’t want to run this in production where it could potentially break something.
  • You will likely use dummy data with a POC. This data could be completely made-up data, or a copy of your production data that has been treated to remove all sensitive information such as confidential information and personal information.
  • POCs tend to be short-term, usually from 1 to 3 months. POCs can be longer, but this is rare.

You should have an agreement for the POC, though this may not be a full-blown SaaS agreement. You will still need the right to access the SaaS system and want robust confidentiality obligations to protect any sensitive information you share with the supplier while testing the system. But POC agreements tend to be stripped down versions of the regular SaaS agreement.

A POC agreement will likely restrict access to only the test environment. Since the SaaS system is usually provided free or for a nominal fee, the POC agreement is unlikely to contain any warranties or indemnities and the supplier will likely disclaim all liability.

Importantly, since the POC is not expected to involve any “live” data, the agreement will likely not contain strong security obligations, nor will the supplier take on any liability for a security or data breach.

Given the limited protections in a typical POC agreement, you should ensure the proper guardrails are in place when running a SaaS system through a POC – for example, no access to production environment and use of test data.

To learn more and join in the discussion, check out my LinkedIn post.

About the Author

More Articles

About the Author

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Articles

SaaS Tips by Sapna | Tip No. 14 – Subcontractors

Your SaaS supplier will almost always subcontract part of the services to a third party so the SaaS

SaaS Tips by Sapna | Tip No. 13 – Pilots

There are similarities and differences between a pilot and a proof of concept in a SaaS agreement.

SaaS Tips by Sapna | Tip No. 11 – Open-Source and Third-Party Software

If the SaaS system includes open-source software, your SaaS contract should contain the appropriate provisions to ensure the

SaaS Tips by Sapna | Tip No. 10 – EULAs

This tip covers when and how to include and negotiate a EULA in a SaaS Agreement.

Most Recent

The Contracts Queen’s Guide to Creating a Practical Contract Playbook

Contract playbooks can be used to improve relationships, empower stakeholders, speed up the contracting process, and save time

Acceptance Terms in SaaS Agreements

Acceptance is an important commercial concept to understand as it pertains to implementation services in SaaS agreements.

Nine Financial Terms Every SaaS Negotiator Should Know

By having a strong grasp of finance aspects of SaaS agreements, you are helping the business win new

Elevating Your GC Brand: 3 Contract-Centric Strategies

A strong GC brand doesn't just bring more influence, compensation, and respect; it also opens doors to the

Subscribe to Contract Nerds weekly newsletter

* indicates required
Professional Role
Generic filters