Launch HN: Common Paper (YC W23) – SAFEs for Commercial Contracts
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 ...
166 comments
[ 0.40 ms ] story [ 245 ms ] threadNevertheless, I like your approach. Kudos especially to open sourcing the contracts--in fact, I think that's critical to success in this space. Open sourcing the terms allows companies to understand them and quickly agree to them with confidence. Wishing you luck!
Who is to say what is substantive to me?
The difference is that the agreements are split up into cover pages, which are designed to be edited/negotiated for different companies and deals, and the standard terms, which are designed to be the same across uses of a particular agreement type.
As a simplified example, the standard terms included a section describing the limitation of liability. In that section, there's a variable for a "liability cap" which gets set on the cover page. The idea is that you might negotiate over whether that cap is $10,000, $1 million, or 2X the past 12 months' fees, but that you rarely need to negotiate the wording of the paragraph describing the limitation of liability.
All that being said, this won't work for every business or deal, but we do hope that it will work for an increasing percentage of them over time.
(This assumes some mechanism for ensuring that what is claimed to be a copy of the standard boilerplate, is in fact such, and has not been sneakily modified.)
We don't yet have a straightforward way to do that for people who are using the contracts on their own outside the software. The best bet for now is probably something like a text diffing tool or Microsoft Word's built in comparisons.
We have some ideas for a native validator for the standards that IMO would be a better solution for those kinds of cases.
This is exactly how it should be.
The last thing I want is "Customer A pushed back against 'We are your exclusive supplier no matter your future price increases' to be "common".
Even worse, the "standard" terms that an employee usually agrees to.
If some side (actually, their lawyer) pushes back on something, then it's not "common", now is it?
This highlights a peril of this sort of approach: were it successful in its mission, a for-profit company would be in the privileged position of getting to define what constitutes “reasonable” agreement terms.
However, the idea of standard, programmable contracts is awesome!
One question: In your example of being forced to use Oracle's paperwork - it's not clear how CommonPaper would solve that - wouldn't you still have been forced to use Oracle's contract?
I've spoken with lots of lawyers in procurement at large companies. They're typically perceived as a cost center, and they often have to deal with lots of people from the rest of the business complaining that the contracts need to be reviewed/approved faster.
If they are processing thousands of vendor contracts per year, think about how much faster they can be if most/all of those contracts are on their in-house template, rather than a different template for each vendor.
But if lots of their vendors are using a standard contract, then there isn't the same cost in terms of time for using it.
All that said, this is going to be hard, and we're not expecting everyone to change overnight. We have, however, been encouraged to see examples of large companies signing the standard contracts, and we're grateful to have attorneys from big companies like Thompson Reuters and Salesforce on our committee.
For the Oracle example, big, old-school companies like this are definitely the hardest to get onboard. However, there are examples of large enterprises adopting standard contracts, including:
The biggest banks in the world trade derivatives using the ISDA master agreement (here's an example of Bank of America that they filed publicly: https://www.sec.gov/Archives/edgar/data/1065696/000119312511...)
The largest ad platforms and advertisers use the IAB standard terms, often with a short addition specific to their company (Here's an example from Disney https://disneyconnect.com/dpep/disney-ad-guidelines/)
We've already seen examples of Fortune 500 companies signing Common Paper agreements, and we're hopeful that it will become more and more accepted by them over time
The NDA is definitely the highest volume agreement, however. And a lot more of the deals are for 10k than $300k.
Stats like those I shared above are from a combination of what users tell us and from aggregated, anonymized metrics across our app.
If both sides are arguing for their own custom template, then it's basically an arm wrestling match and whoever has the most leverage wins. If one side instead says "We adopted this independent standard created by attorneys from a bunch of companies" they get more leverage while being less adversarial.
Our early users saw a significant increase in the percentage of deals on their own paper (which is/was the standard) before they could be getting any benefit from the customer having seen the agreement before.
I expect that the agreements will just work for some countries, require minor changes for others, and in some cases need to be basically rewritten from scratch.
If you do take the agreements to a local attorney and find out what does and doesn't work in your country, we'd be really grateful if you shared that feedback. We've had a few people do that already, and it's helped in our plans for expanding into natively supporting other countries.
The attachments (essentially similar to the terms in Common Paper) are readable in English at https://it-ehdot.fi/tutustu-ehtoihin/ ("ENGLANNIKSI" tab), but the agreement template (similar to the cover letter) requires buying them.
Since this is (apparently) one of a zillion companies to do this, I think we should probably just treat this as off-topic and make our great stand on Rob's sso.tax page somewhere else.
> The process for creating and revising the contracts is modeled after an open-source software project Which Open Source Project? Could you link it please?
What do you mean by Open Source Contracts? Do you mean community edits & maintains contract templates?
Do you have APIs to integrate?
Do you have your own way of signing contracts or use third party tools like DocuSign?
> The process for creating and revising the contracts is modeled after an open-source software project Which Open Source Project? Could you link it please?
We didn't model it after a particular open-source project. Rather, we tried to take lessons learned from open-source software projects in general and apply those lessons to the creation and maintenance of the standard contracts.
> What do you mean by Open Source Contracts? Do you mean community edits & maintains contract templates?
There's a few elements of what we mean by this: - The contracts are released under the Creative Commons CC BY 4.0 license. It shares a lot of principals and goals with the OSI licenses for software (eg Apache and GPL) but is built for things other than software - Yes, the community edits and creates the agreements. The community members are largely attorneys rather than software developers, and you can see a list of some of the most active members here: https://commonpaper.com/committee/ - We have an amazing attorney on our team who is analogous to the maintainer of an open-source project. She solicits and collects feedback from the community and makes the final decision about what does and doesn't get into any particular release.
>Do you have APIs to integrate?
Yes, and you can see the docs here: https://api.commonpaper.com/docs
>Do you have your own way of signing contracts or use third party tools like DocuSign?
We embed Dropbox Sign (formerly HelloSign) within our product for this step
1. We didn't model it after a specific open source project, but Jake worked on https://www.singer.io. We do take inspiration from Open Source licenses like Apache 2, GPL, MIT, etc.
2. Open source in the sense that the terms of the contract are open source and released under a CCBY license. Terms are available via versioned URLs, github markdown source control, and maintained by a committee of contributors (attorneys).
2. Yes! You can find our REST API docs here: https://api.commonpaper.com/docs. It uses the JSONAPI spec.
3. We're currently integrated with Dropbox Sign.
This is a cool idea, but the irony here is that Oracle probably still wouldn't use the Common Paper contract and insist on their own contracts instead. So am not sure if it is solving this particular problem.
We're also encouraged by the examples of standard contracts in other domains that have gotten traction with large enterprises. Basically all of the big banks use the ISDA master agreement^1 for financial derivatives, and the vast majority of ads sold on the internet use the IAB standard terms^2.
1 https://en.wikipedia.org/wiki/ISDA_Master_Agreement
2https://www.iab.com/wp-content/uploads/2015/06/IAB_4As-tsand...
I really like the framing of "an enduring organization that is widely trusted." Many of these are industry associations, but YC doesn't fit that criteria with the SAFE. Your definition captures all of the examples I can think of.
So assuming you’re charging for the contract management piece, who is the target customer (and how much do you charge)? Or do you provide some other value that I’m not seeing?
Small startups don't need contract management until they reach a point and then they wish they started doing it from day 1. :)
"hyper-standardized contracts" I suggest you take a look at the app! While our terms are immutable, the contracts can be heavily customized. So instead of hunting down a random word in a PDF you can focus on the things the material changes from agreement to agreement.
Full details on pricing here: https://commonpaper.com/pricing/
Our target customers are B2B SaaS companies, and our goal is to have them start using us when they are small on the free version and grow with them.
I agree that the bigger entities are the hardest ones to get onboard with this, but our users have signed contracts with Fortune 500 companies and large universities, including deals for hundreds of thousands of dollars. It's actually in the cases where there's a big mismatch in size that we can provide the most help, although there are plenty of cases where the big company draws a hard line and won't use anything but their in-house contract.
One question: how do you make sure that all of the different allowable options make sense together? For example, I see a governing law option. Can you only select from a few, pre-vetted options? What if someone selects a jurisdiction whose governing law isn’t compatible with other provisions in your contract (for example, termination terms or indemnification)? You wouldn’t want to give your customers the sense that they can play with terms like Lego blocks and be guaranteed that the result is something sensible, if this is not the case.
One thing I'll note is that we do support importing contracts on customer paper / or deals executed outside our system. We only have a subset of our features for those, but all of your contracts can be together in the same system.
On the options making sense together, the standard agreements are created by 40+ attorneys specializing in tech law and commercial contracts. They design our contracts to reflect what is industry standard with a focus on creating a fair and balanced starting point. That being said, each company chooses how they want to configure their own cover page. We provide tooltips and help articles on what the terms and variables mean, and companies can work with their attorney to set it up initially or include them in the workflow. We can intro our users to attorneys who are familiar to with the standards and do good work.
If the pitch is that it would save money on legal fees, then that could be a big value add. But if that's the angle, then my last question, regarding whether the docs are meant to be closed-universe and vetted, or open-universe and not vetted becomes critical. Founders wouldn't want to be changing options around and not realizing that they are creating confusing or unexpected results.
If they're supposed to still use a lawyer, then that blunts the value add (and the lawyer would likely resist the standardized agreement because it means fewer billable hours). But maybe you can get enough critical mass to be an 800-lb gorilla, like the SAFE has become? I appreciate the quick responses here, and am taking a look at the agreements to see if they could be relevant for our business.
By making contract review and negotiation faster, we speed up your sales cycle and grow revenue faster. Faster sales cycles mean that you get paid faster, which in turn means that you can recycle cash into new customer acquisition investments and grow faster. We wrote a blog post about the math of how sales cycle speed translates to revenue growth here: https://commonpaper.com/blog/impact-of-accelerating-sales-cy...
Some of our users work with attorneys, and some do not. For the folks who do work with attorneys, we still make those relationships more efficient because the scope of negotiation is more narrow. As a simple example, if the attorney helps the founder understand the implications of increasing or decreasing a liability cap, it's straightforward for them to apply that info on their own for many deals in the future. With traditional bespoke contracts, if they see a bunch of redlines to a paragraph about liability, it's much harder for them to reason about whether or not this is safe to sign.
We try to help users understand what sort of information tends to go in each variable, but we stop short of providing customized advice. So we can help people understand that a liability cap might be a fixed number (eg $1 million), a multiple of fees paid (eg 1X the last 12 months fees), or unlimited. But we can't advise them on whether or not their particular company should take the risk of a particular level of cap in order to close a particular customer. That's the sort of thing they should talk to an attorney about.
While we certainly are using technology to help solve the problem, it's more about creating contracts in a way that helps you focus on the key changes from contract to contract. When you build on immutable terms, and the only changes are in the contract's cover sheet, you can focus on the changes and not hunt down for words inside of an inscrutable PDF.
Having deep insights into the mindset and financial incentives of lawyers would seem to be key here (but if you're funded by YC, presumably you've already been asked this question and come up with a good answer!).
While there are important differences in our approaches and focus areas, I'm a fan of more adoption of standards in general and there's a lot that we agree on.
Some companies choose Common Paper over Bonterms because we offer agreement types that they don't, including a Design Partner Agreement and Partnership Agreement. As far as I know, they only provide agreement templates and not software to manage them.
When lots of organizations use standard contracts, everyone becomes more efficient regardless of what tech they use (or even if they're just working with contracts manually). Standardization also enables us to build a different kind of software for managing contracts
So this is exciting! I am delighted!
I just wish I were in the target audience. My business is not a startup, and I'm going to need specific terms because I'm a one-man shop. (How do you handle taking a vacation as a one-man shop? Work will effectively cease.)
Maybe I'll look at the contributor list and find an attorney in my state, which would still be vastly useful to me.
They can potentially help with configuring the standards for your business and/or drafting something custom if none of those are a fit
I still might use the contracts, though. Thank you.
Can you tell me how to make my business run without me using that model? Most startups don't do support for this reason; I'm pretty sure it's impossible to do support without an available person.
But it's not unprecedented. Think Daniel Stenberg of libcurl.
I have been thinking about how to handle this problem, and I'm not sure of the solution.
In Hollywood, a lot of stuff is agreed upon without a contract. How does that work?
If your instinct is to say "it's a disaster," this will fail.
That's the set of contingencies that contracts are supposed to address.
One guess is that it might be a relatively small community where the same people and companies do business with each other over and over. In a community like that, some of the jobs that contracts do in other industries might be done through norms and relationships.
I enjoyed "Why Trust Matters" by Ben Ho (https://www.amazon.com/Why-Trust-Matters-Economists-Guide/dp...) and it talked about a sweet spot where contracts shouldn't try to over or under-specify the deal in order to optimize for trust. I'm sure that some industries, like Hollywood, have less laid down in contracts than others.
If you're open to it, I'd love to hear more about how you've seen this work in Hollywood.
> If you're open to it, I'd love to hear more about how you've seen this work in Hollywood.
There's so much to say. But maybe the most important thing to you is that entertainment lawyers are customarily paid 5% of the transaction's value to their client. So you get quality and often creative legal advice, with aligned incentives, whether you're Leonardo DiCaprio or some nobody.
Every startup is a nobody.
By the time YC published the SAFE, it had a lot of soft power and influence in early stage investing, because it could coordinate with every YC startup in the batch and give them cover if an investor had an issue with the SAFE. They essentially had a "union" (on the startup founder side) with critical mass, which when they all demanded the use of the SAFE instead of bespoke docs (which many investors to this day still try to mess with the standard SAFE), it just became easier for the whole industry to adopt the standard.
I'm curious how you guys are thinking about achieving that effect in the realm of each type of contract? Because on a 1-1 basis, it seems like the bigger party will always just demand their lawyers' preferred contract, and they can have a lot more leverage than a smaller startup.
The other challenge I can see is that ultimately, there's a perverse incentive when it comes to the lawyers. In my experience, large corporate firms like Orrick and WSGR are pretty aligned, because they want the long-term relationships with tech startups. But this product objectively reduces the need for lawyers (which I'm all for, btw!). For larger companies, where they pretty much pass it to their retained law firm at the contract stage of the process, what incentive is there for the lawyers to go with the standard contract (low billable hours), versus a bespoke contract (where they'll make a lot more money)?
Or I guess, how are you guys getting around the lawyers and selling the companies themselves, over the probable objections of their law firms?
I love this, and it seems you've already gotten some good traction, good luck!
For us, it's about providing day 1 value to the users of the contracts that does not depend on the agreements already being widely adopted. One example of that is our Stripe integration, which enables our customers to automatically bill their customers once they sign a contract. This uses the information already in their contracts, and it saves a lot of manual work and helps them get paid faster, and is separate from the negotiation benefits.
The other thing I'll point out is that our users have been seeing more success in using the standard contract from when we released our original NDA. Instead of losing an arm wrestling match because they have less leverage, they can say something like, "We adopted this standard agreement created by a committee of attorneys." That doesn't work every time, but we've seen some companies cut the percentage of their deals on customer paper in half.
We've seen a big range of reactions from attorneys. While we have some big supporters (and committee members) at law firms, we've gotten more traction with in-house counsel. I think it's at least partially because of the reasons you outlined. I do hope to get all the law firms on board as a channel eventually, but for now, we're focusing our energy on the companies themselves.
Excited to see this take off!
Do you plan on offering migration services from Ironclad? That would amount to importing our workflows and repository.
How would you integrate an LLM into this?
1) Document search 2) Translating plain english <> Legalease
But seems like the highest leverage here is building a copilot for authoring new contract templates that Common Paper doesn't offer yet (maybe the legal advisory panel could assist with RLHF training).
I think what’s cool about CommonPaper is not just having the negotiations scoped to smaller areas but also the affect on the sales cycle. If can trim months off a deal process, that can help save a startup in terms of resources spent and dollars coming in earlier.
Full blog post and math here: https://commonpaper.com/blog/impact-of-accelerating-sales-cy...
I bet this is gonna raise funding though
For each contract, we go through a multi-month process with 40+ attorneys to vet the standards against all of the permutations they've seen without making the agreements too complex.
On the software side, this is a big part of the value of structured data. We make it easier to keep track of the different variations you've agreed to in different contracts. It's a tricky balance to make sure our users are never constrained from closing new customers while still making sure the software sticks to and takes advantage of the standards.
Good luck, great idea! From a technical perspective, I especially appreciate the notion that much of the wording can be standardized, with key variables identified and extracted as structured data.