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

How to Draft Better SOW Requirements to Improve Contract Performance

Even though SOW requirements are usually drafted and approved by business folks, legal teams can add value.

A Negotiation Playbook for SaaS Agreements: Preferred Terms for Vendors vs Customers

Top 15 issues in SaaS agreement negotiations from the vendor side vs. the customer side.

Payment Terms in SaaS Agreements

The more certainty that a SaaS Agreement provides on payment terms, the less likely the parties will have

Seven Tips to Draft a Balanced Contract that Speeds Up Deals

If you want to speed up deals, there’s one thing to keep in mind above all else: business

Contract Nerds Logo

Download PDF

[download id='9545']
Search
Generic filters