I (Jake) was a co-founder of two B2B SaaS companies, RJMetrics (where Ben and I met), and Stitch. Everything about contracts was frustrating, both at those startups and the larger companies that acquired us.
Way too often, the contracting process with a customer got adversarial—arguing over whose template to use, emailing Word docs back and forth, huge legal fees, and unpredictable delays that made it hard to know if a deal would ever close. Then, when we finally got the customer to sign, we had to keep track of all of the promises embedded in the contract. This is difficult when you have hundreds of customers and contract PDFs full of unstructured text.
The breaking point came when one of our customers was acquired by Oracle. They wanted to keep using our product, but had to move from our original contract to the one that Oracle uses. In exchange for this, they were willing to increase the price they were paying from $6,000 to $24,000 per year.
It took us 9 months to get the new contract in place, just to enable them to keep using the product. We spent more on attorneys than we gained from the upsell. And there was basically nothing we could do to improve that process as a single company operating in a system where standards don’t exist.
Contrast that to the standardization that the SAFE, or Simple Agreement for Future Equity, brought to seed investments, and the potential is obvious. (Past discussion of the SAFE at https://news.ycombinator.com/item?id=33639191)
If you’re a startup raising money on a SAFE, the process is simple, whether you’re raising $10k from an angel or $1M from a VC. Everyone already uses, or at least is familiar with, the same basic contract. There are a few variables that change on a deal-by-deal basis, but the transactions are vastly more efficient because everyone is on the same standard contract.
If you start with standard contracts, you can build very different software to manage them compared to traditional contracts. Our business model is to provide the standard contracts for free and charge money from companies who use our software to sell to their customers (more on this below).
The standard contracts we create are all related to buying and selling B2B software. This includes a non-disclosure agreement, (https://commonpaper.com/standards/mutual-nda/), sales contract (https://commonpaper.com/standards/cloud-service-agreement/), SLA, DPA, ToS, etc. The full list is at https://commonpaper.com/standards/.
The process for creating and revising the contracts is modeled after an open-source software project, and they are released for free (as in both speech and beer) under the Creative Commons CC BY 4.0 license.
We have a committee of 40+ attorneys from tech companies and law firms who are analogous to code contributors (https://commonpaper.com/committee). An attorney on our team, who you can think about like a maintainer, collects all of their feedback and synthesizes it into a version for release (eg the Design Partner Agreement v1.0). We post the agreements as DOCX, PDF, and HTML on our website and host markdown on Github.
Most of the usage of the agreements happens outside of our platform, and we don’t have any visibility into that unless people choose to tell us. However, we do know that thousands of companies have signed the agreements, and millions of dollars worth of deals have been closed on them.
Each agreement is split into two sections: the standard terms, which are the same across all instances, and a cover page, with variables that can be customized for a particular company and deal. The latter is basically a schema for each agreement type, and that leads to the fundamental trade-off in how we build our software. We have less flexibility around types of contracts (because we’re focused on the standard agreements, not arbitrary DOCX files), but in exchange, every agreement type has a consistent data model, which means that we can build integrations and features that work across all customers. This gain is huge.
For example, we can use the data in the fees section of our standard Cloud Service Agreement to automatically generate invoices and subscriptions using Stripe. Similarly, it’s trivial to use our API (https://api.commonpaper.com/docs) to check if an active NDA is in place before sharing confidential information or to keep a spreadsheet up to date with the SLA obligations for different customers.
Traditional contract management tools are built around adding electronic signatures to documents full of unstructured text and/or creating a custom data model from a particular company’s bespoke contract. There’s no way they can offer features like this without a custom project for each particular contract. It’s basically the difference between custom software and a software product.
Part of our feature set overlaps with the traditional tools. We can do things like send a contract to the other side, propose changes, approve, and sign. But our negotiation model is different in that it encourages both sides to keep changes narrowly scoped to the variables in the cover page. That makes it faster both to propose the changes and for each side to understand, and accept or reject, the changes proposed by their counterparty.
We believe that, just as with SAFEs in the investment world, the potential efficiency gains and positive side effects of this model are so big that the transition is inevitable. We’d love for you all to try it out and let us know your feedback and suggestions. The agreements are free forever, and our software is free as well until you use it to close deals with 5 customers. https://commonpaper.com/product/.
We’re interested to hear about any experiences you’ve had with contracts and how you’ve worked with them. We look forward to your comments!
by Andrey
Azimov