[HN Gopher] Launch HN: Common Paper (YC W23) - SAFEs for Commerc...
___________________________________________________________________
Launch HN: Common Paper (YC W23) - SAFEs for Commercial Contracts
Hey HN, we're Ben and Jake, founders of Common Paper
(https://commonpaper.com). We provide standard, open-source
contracts and a platform for getting them signed quickly. See
https://youtu.be/f7maIapJpU4 for an overview, and
https://youtu.be/A1PWjWiheFk for a demo of sending and signing a
contract. 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!
Author : jakestein
Score : 304 points
Date : 2023-05-23 13:28 UTC (9 hours ago)
| frasermarlow wrote:
| Congrats Jake, Ben, and the whole crew. Another great Philly
| jawn.
| bengarvey wrote:
| But also we are fully remote!
| sbolt wrote:
| Is this similar to https://bonterms.com/?
| mchusma wrote:
| I do love the concept. I could see us using the standard terms. I
| am not sure about spending $5 per contracted customer per month
| forever. This seems like a lot. It feels like it should scale
| down or something, maybe $1/mo? or $5 per contract? Maybe the
| answer is cheap people can just use the open source docs without
| the tools...
|
| I like the concept, I just don't see how I could pay for this at
| my (bootstrapping) company!
| jakestein wrote:
| That's good feedback on our pricing, thanks for that. One thing
| I'll clarify is that this is just for customers with whom you
| sign contracts. If you have self serve customers that do click
| through agreements, we don't charge you for them.
|
| A common pattern we see among our users is that they have a
| high volume of low priced customers on their self serve plans,
| and then a smaller number of high dollar customers on something
| like an enterprise plan. These enterprise customers are the
| ones where you need to sign contracts and have negotiations.
| That's more the case where our software is helping, and it's
| only these that we charge for.
|
| And yes, you're always welcome to use the open source docs for
| free if the software doesn't make sense for you.
| smcavinney1 wrote:
| We've been using CommonPaper for our contracts and NDAs since we
| started selling. It's been super useful during negotiations and
| makes it way easier for clients who don't have lawyers to
| understand what's going on in the terms.
|
| Congrats team on the launch!
| doctorpangloss wrote:
| > Everything about contracts was frustrating, both at those
| startups and the larger companies that acquired us.
|
| 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.
| dsr_ wrote:
| It's only a disaster when there's a non-simple failure on one
| part or the other.
|
| That's the set of contingencies that contracts are supposed to
| address.
| [deleted]
| jakestein wrote:
| I don't have experience with contracts (or the lack thereof) in
| Hollywood, and that's interesting to hear.
|
| 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.
| doctorpangloss wrote:
| I signed up, it's valuable to me at AppMana. Trust resonates
| with me.
|
| > 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.
| jakestein wrote:
| Oh interesting, I could see how a percentage of the
| transaction's value could totally change the incentives and
| behavior compared to hourly billing. Thanks for sharing
| that and for signing up
| abewheeler wrote:
| We use Common Paper for a bunch of our Cloud Service Agreements
| over at Trigo. Really saved us a ton in time and legal fees! Keep
| up the great work Jake & Ben!
| bengarvey wrote:
| Thank you!
| mschuster91 wrote:
| Wow, that does look awesome. However it seems that all the
| contracts use typical US boilerplate language - do you have any
| plans to make derivatives usable for the major European
| economies?
| jakestein wrote:
| The short answer is yes, we do plan to add versions for other
| countries. I expect Canada to likely be the first country we
| add, followed by the UK.
| nkko wrote:
| This guy Art Vandelay is a real piece of work, consider all
| agreements with him with top care.
|
| Btw love the product. Would be nice to have optional blocks with
| explainers. Something like special terms. Also, LLMs would be
| nice so that you could 'chat' with the document to understand it
| better. Make it explainable. Or to help you define specific parts
| such as the subject of the NDA, which are typically too broad or
| undefined. LLMs could help users better define those parts by
| asking questions and writing the subject section.
| jakestein wrote:
| I suspect you might enjoy signing an NDA with Vandelay
| Industries https://app.commonpaper.com/pages/eceaa29b0494074a
|
| Great point on optional blocks/special terms. We have a project
| on the roadmap to make it easier to incorporate entries from
| the language library into your agreements
| https://commonpaper.com/language-library/
|
| We're always looking for additional ways to help people
| understand the agreements and figure out how to configure them.
| I agree LLMs could provide help there, and it will be fun to
| figure out the right way to leverage them
| singleshot_ wrote:
| The optional block/explainer bit is how Westlaw practical law
| works. It seems like the main advantage of this over having
| lawyers who each have access to some tool that is proposing
| optional sections is that in this model, the end users agree to
| limit themselves to the optional blocks but they aren't getting
| advice on what they mean.
|
| The first is an improvement but without the second I'd be a
| little concerned. The construction industry has stock contracts
| like these and I've seen them go sideways for sure.
| jakestein wrote:
| To your point about advice on what the blocks mean, we've
| started to do two things related to this, and I'd be
| interested to know if either are close to what you have in
| mind.
|
| 1) We have a language library
| (https://commonpaper.com/language-library/) of optional
| sections to add for specific use cases. Most of them don't
| yet have much context beyond the language itself, but here's
| a page where we provide an explanation
| https://commonpaper.com/standards/mutual-nda/account-mapping
|
| 2) In certain places within the app, we have tooltips with
| short explanations and links to longer help articles. So when
| you hover over "Auto renewal" we pop up the text "At the end
| of this contract, do you want your customer to automatically
| roll into another contract on the same terms? Learn more."
| jakestein wrote:
| I'd also be interested to know which standard contracts
| you've seen in the construction industry. We're always
| trying to learn from other, related projects
| singleshot_ wrote:
| ConsensusDocs would be one I've seen end up in a big ol'
| fight. I gotta spend a little more time to answer the
| other question, though.
| jakestein wrote:
| I had not heard of ConsensusDocs, thanks for sharing. I'm
| especially fascinated by cases like these where you have
| to pay for access to the standard contracts. Looking
| forward to learning more about them.
|
| Sounds good re the other question, thanks in advance
| gervwyk wrote:
| Really cool resource and congrats on the launch! It would be
| great to see more supported countries, I guess beside some
| technicalities, it will be the same for many?
| jakestein wrote:
| We do hope to support more countries in the future. Right now
| the committee of attorneys that make are agreements are largely
| based in the US, and the agreements are made with US law in
| mind.
|
| 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.
| buzer wrote:
| There are likely similar things already in some countries. I
| know Finland has IT-ehdot (IT-terms), they are made by a group
| of organizations (the Finland Chamber of Commerce, Technology
| Industries of Finland, Finnish Association of Purchasing and
| Logistics LOGY, Finnish Information Processing Association
| TIVIA and the Finnish Software and E-business Association)
| though they are not free. They tend to get updated every 4-5
| years.
|
| 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.
| jakestein wrote:
| Oh wow, I have been researching standard contracts for years
| and I keep finding out about new ones. I'm going to read up
| on these Finnish standards, thanks so much for sharing.
| Foobar8568 wrote:
| Do you offer integration with docusign or Adobe? I failed to
| understanding the signing process. I am not the target
| demographic but I toyed with the idea of such products as this
| field is a total mess.
| jakestein wrote:
| We embed Dropbox sign in our product in all of our tiers. We
| can also integrate with company's Docusign or Adobe sign
| accounts, but it's not part of the default offering
| carlosdp wrote:
| Congrats on launch!
|
| 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!
| jakestein wrote:
| I appreciate that, and you're right that overcoming the cold
| start problem is the key to establishing a standard. We've
| tried to learn what we can from how YC published the SAFE, as
| well as other standard contracts like the NVCA model docs, IAB
| standard terms, ISDA master agreement, etc.
|
| 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.
| carlosdp wrote:
| Yea definitely makes sense to me that you're concentrating on
| the company's experience! It's also such a massive market
| (just like, _all_ companies), that there 's an insane amount
| of room to grow, even without tackling the david vs goliath
| problem.
|
| Excited to see this take off!
| sidcool wrote:
| Congrats on launching. This is a very new area for me. How does
| tech solve this problem?
| jakestein wrote:
| Your intuition is right, and in our view tech only solves part
| of the problem. We believe that the actual content of the
| contracts needs to get standardized, in addition to deploying
| tech against the contract problem
|
| 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
| sidcool wrote:
| Thanks for responding. At first glance it seemed like a smart
| contract solution. Good luck!
| mNovak wrote:
| Looks nice, congrats on launch! I hope to see this concept expand
| beyond SaaS.
|
| My company deals a lot with government contracts, which is a
| slightly different beast in that they are actually semi-
| structured (via FAR and DFAR), but would be extremely useful to
| have tools to help us understand and track our contracts at a
| glance, and create compliant sub-contracts (for instance identify
| flow-down clauses).
|
| Probably such tools exist, but gov contracting tools are
| typically extremely expensive, not targeting small business.
| jakestein wrote:
| That's really interesting, I'm not familiar with FAR and DFAR
| but spent a few minutes reading about them and I'm looking
| forward to learning more.
|
| We do plan to expand beyond SaaS later on. What kinds of
| products and services does your company sell to government?
| melvinmelih wrote:
| > 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.
|
| 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.
| jakestein wrote:
| Oracle and companies like it are definitely the hardest to get
| on board. That being said, our users have already closed deals
| with Fortune 500 companies using the standard contracts, and
| they see a big decrease in the percentage of deals that they
| have to do on their customer's contracts.
|
| 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...
| matthewmcg wrote:
| Came here to make the comment that there are certain industry
| specific contract forms that are very deeply embedded in very
| narrow domains, including things like NAEBs (natural gas
| commodity sales) and the AIA Contract Forms (construction).
| And of course real estate. Some are publicly available.
| Others need to be purchased from the organizations that
| create them. The common factor seems to be sponsorship by an
| enduring organization that is widely trusted.
| jakestein wrote:
| I had heard of the AIA forms but not the NAEB, thanks for
| sharing that one. Looking forward to checking it out.
|
| 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.
| jagged-chisel wrote:
| Today, no. But if the industry can standardize, it might get
| the behemoths to consider similar frameworks for the reduced
| expense and increased predictability. Maybe it won't solve that
| particular problem today, but it stands a chance of improving
| things in the future ... IFF someone is willing to start
| something now.
| jakestein wrote:
| This is well said and a really important point that I often
| forget to highlight. If we're successful, the big companies
| will see a huge benefit.
|
| I've interviewed a bunch of folks on enterprise procurement
| teams. They won't be early adopters, but they do want
| something like it to exist.
| gamblor956 wrote:
| Ran it by our Legal Department. The inability to customize all
| aspects of the contracts to handle specific needs for each
| contract renders this DOA.
|
| What you see as unnecessary negotiation over "standard terms"
| they see as protecting the company's specific interests based on
| its needs and risk tolerances. By eliminating that, you've
| eliminated most of the potential market, since differences over
| "standard terms" usually reflect significant differences in each
| parties' specific legal needs and risk tolerances. It seems that
| you're targeting SV tech companies that all use the same group of
| VCs, which explains why they have a lot of standard terms they
| can all agree on. But once you expand outside of this narrow
| niche (and especially if your contracts involve foreign
| counterparties), this list of common standard terms selected by a
| third party that both counterparties can agree on without review
| or negotiation goes to zero. Even just a cursory review of the
| Professional Services Agreement raised several huge red flags
| that no competent Legal Department should agree to...
|
| Also, any company that needs standardized contracting so they can
| automate processes based on that is large enough that they can
| simply demand their counterparties use their standard
| contracts...you're not getting Oracle and Apple or large
| companies to use these contracts (and especially not non-tech
| companies), and that means any customers who are dealing with
| such counterparties will need a separate process for handling
| those contracts, which makes contract management _more_ complex,
| not less.
| jjlustig wrote:
| You also are going to quickly run into scaling issues. A main
| sell is that you have a team of "experts" draft the standard
| terms. But this means a new "expert" team for every new
| contract-type AND industry. The same type of contract (e.g., an
| MSA) can look very different in tech (where most of your expert
| attorneys work) than in pharma, ag, or oil & gas, for example.
|
| Trust is also a big issue. "Standard" is never really standard.
| Contract language is always going to be biased towards one side
| of a deal. Take NVCA forms. They claim to be "model" but the
| language generally is drafted to favor VCs over founders. How
| can one trust that your "expert" group is creating truly
| neutral forms?
| jakestein wrote:
| Totally agree that this won't work for all companies or
| situations. You're right that our initial target market is
| technology companies, although many of our users are outside
| Silicon Valley.
|
| I also agree that getting large companies to agree to use the
| standards will be hard, but there examples of them adopting
| other standard contracts:
|
| Here's Bank of America entering into the ISDA Master Agreement
| for financial derivatives
| https://www.sec.gov/Archives/edgar/data/1065696/000119312511...
|
| and Disney using the IAB Standard Terms for online ads
| https://disneyconnect.com/dpep/disney-ad-guidelines/
|
| We've already seen our users closing deals with Fortune 500
| companies using the standard contracts, but we have a lot more
| work to do on that front.
| gamblor956 wrote:
| Bank of America and Disney's ad department are using
| _industry standard_ contracts for high-volume automated
| transactions where negotiation is not required or allowed,
| and review is not required by Legal prior to entry or
| execution.
|
| Your product is intended for low-volume transactions that are
| intended for Legal to review before signing.
|
| It's not even remotely the same thing, and if your advisors
| have suggested otherwise you need to replace your advisors.
| jakestein wrote:
| I agree that many of the transactions on the IAB Standard
| Terms and ISDA Master Agreement are automated and don't
| involve negotiations. There are, however, also higher
| dollar value ad buys and derivative transactions that use
| those standard agreements and do involve negotiation.
|
| I had a helpful conversation with an attorney who was
| previously at Facebook about this. They use the same basic
| addendum to the IAB Standard Terms for most of their ad
| sales, and they sometimes negotiate it with large
| customers.
|
| We see a similar pattern among our users, where their lower
| dollar, high volume transactions don't involve negotiation,
| but their bigger deals do.
|
| We don't yet have the same distribution as the IAB or ISDA,
| but our goal is that over time more and more companies will
| be able to focus just on the variables in the cover page of
| our standard agreements because their team has already
| reviewed our standard terms.
| sghosh2 wrote:
| I've seen so many deals get hung up on the smallest legal issues.
| One time a company spent 6 months just negotiating the NDA before
| could even get to a POC that the champion kept pushing and
| wanting to do!
|
| 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.
| jakestein wrote:
| That's a good point, and the magnitude of the impact of
| speeding up sales cycles can be really surprising if you
| haven't done the math. We wrote a blog post about this last
| year with a model in Google Sheets that you can customize for
| your business, but the TLDR was that while holding everything
| else constant, moving the sales cycle from 4 month to 3
| increases ARR by 46%. That's with the same starting capital.
|
| Full blog post and math here:
| https://commonpaper.com/blog/impact-of-accelerating-sales-cy...
| 0xa2 wrote:
| You picked a great name! I wish we could see something similar
| for the HIPAA business associate agreements in healthcare. It's
| pretty standard language, and a substantial part of healthcare
| contracts. I had to chuckle about the choice of court example on
| your website - it comes up so frequently, even I am aware of it,
| despite being on the tech side.
| jakestein wrote:
| I really appreciate that, and stay tuned for a standard BAA
| coming soon. If you'd like to get a preview, email me jake at
| commonpaper.com
| klysm wrote:
| Really sad to see https://sso.tax/ being employed here. Please
| let your customers use your software securely.
| tptacek wrote:
| This is just asking for a long off-topic thread but as one of
| HN's resident SSO nerds: you don't have to listen to people
| demanding that you eliminate the "SSO tax". Paying for SSO is
| super annoying, and I'd rather not pay it either, but I'd even
| less rather see companies go out of business because they're
| not generating revenue. This "tax" is popular because it's one
| of the more effective customer segmentation levers that exists.
|
| 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.
| joshpadnick wrote:
| Your main pitch is on open source standardized contracts and that
| definitely resonates, but as a current Ironclad user where
| they're our single-most expensive SaaS subscription, your
| contract lifecycle management system built for startups is what
| resonates for me.
|
| Do you plan on offering migration services from Ironclad? That
| would amount to importing our workflows and repository.
| jakestein wrote:
| I would love to have you as a customer, but I'd have to do more
| research on what it would take to import the workflows and
| repository. If you're open to talking about this, my email is
| jake [at] commonpaper.com
| calny wrote:
| Congrats on the launch! There's certainly a "problem" worth
| solving here. I'm a lawyer, and it's crazy that I occasionally
| actually have to negotiate non-substantive parts of contracts
| like severance clauses. There really should be standardized
| boilerplate for at least some provisions (like you're doing),
| where companies can quickly say "we are using the common terms",
| and if another side pushes back it raises questions. That said,
| it's tricky to deal with edge cases, differences in state law,
| etc.
|
| Nevertheless, 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!
| jakestein wrote:
| I really appreciate the kind words, and I totally agree that
| there will edge cases that the standards don't yet support. Our
| goal is to gather feedback on things like that (and places
| where the contracts can be simpler / easier to understand) and
| incorporate that into future versions. We're always looking for
| more great attorneys to get involved, and if you have any
| interest, you can fill out the form on the bottom of this page:
| https://commonpaper.com/committee
| lelanthran wrote:
| > There's certainly a "problem" worth solving here. I'm a
| lawyer, and it's crazy that I occasionally actually have to
| negotiate non-substantive parts of contracts like severance
| clauses. There really should be standardized boilerplate for at
| least some provisions (like you're doing), where companies can
| quickly say "we are using the common terms", and if another
| side pushes back it raises questions.
|
| 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?
| MacsHeadroom wrote:
| As a serial business owner and principal, it's crazy that
| anyone expects me to agree to boilerplate contracts without
| negotiation. Boilerplate is a first draft as far as I'm
| concerned.
|
| Who is to say what is substantive to me?
| jakestein wrote:
| Just to clarify, we do expect people to negotiate the
| contracts, and most of our users negotiate on at least some
| portion of their deals.
|
| 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.
| snewman wrote:
| I think the value here is around _starting with a known
| default_. If someone hands you a contract which consists of a
| known boilerplate plus three changes, then (assuming you 're
| already familiar with the boilerplate) you don't need to
| carefully read the entire contract word for word, you only
| need to look at the three changes, plus whatever
| customizations you'd like to propose. For the vast majority
| of the terms where neither party feels a need to deviate from
| the standard, you get two benefits: (1) the drafting party's
| lawyer won't put in onerous terms just to see whether they
| can get away with it, and (2) you don't need to read it
| carefully, because you already know what it says.
|
| (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.)
| martypitt wrote:
| This sounds very interesting. Your website doesn't appear to be
| loading. (edit: It's now back up - thanks!)
|
| 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?
| randyzwitch wrote:
| Agreed...feels like this is as much a cultural problem as a
| tech one. Meaning, from my experience at large companies, I
| feel like those lawyers get off on the fight of who gets to
| write the terms
| jakestein wrote:
| Culture is definitely part of the problem, and I completely
| agree that tech alone can't solve it. I also think it's
| critical to change the incentives that lawyers are responding
| to.
|
| 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.
| maccard wrote:
| If company A manages to convince Oracle to use CommonPaper's
| agreement, it clears the way for startup B to use the same
| agreement, without spending months on lawyers!
| jakestein wrote:
| That's right, and the other thing I forgot to mention is that
| we're seeing evidence that it becomes easier for company A as
| well.
|
| 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.
| jakestein wrote:
| Shoot, thanks for flagging the website. I think we have it
| working now but trying to make sure it stays up.
|
| 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/10
| 65696/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
| gnicholas wrote:
| When you say Fortune 500 companies have signed your
| agreements, are these material agreements, or NDAs and small-
| dollar contracts? Or are they signing six- and seven-figure
| deals on your paper?
| jakestein wrote:
| Some of them are six-figure deals. I don't personally know
| about any seven-figure deals, but we only find out about a
| minority of the use of the agreements.
|
| The NDA is definitely the highest volume agreement,
| however. And a lot more of the deals are for 10k than
| $300k.
| bombcar wrote:
| How much can you "see" of the contracts being signed? Is
| it a "we just promise not to look, much" or are they
| encrypted such that you need customer permission to view?
| jakestein wrote:
| We would not need a customer's key in order to access a
| contract. However, only certain members of our team have
| the ability to access contracts, and they only do that
| when needed for support or to fix a bug. We log all
| instances of accessing a customer's account.
|
| Stats like those I shared above are from a combination of
| what users tell us and from aggregated, anonymized
| metrics across our app.
| gavinhoward wrote:
| I am building a business right now, and I need a standard
| contract for customers.
|
| 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.
| jakestein wrote:
| If you send us a note at support@commonpaper.com, we'd be happy
| to make an intro to one of the attorneys on the committee.
|
| They can potentially help with configuring the standards for
| your business and/or drafting something custom if none of those
| are a fit
| gavinhoward wrote:
| Thank you for the offer. I just went through the list, and
| unfortunately, I found none in my state. :(
|
| I still might use the contracts, though. Thank you.
| oldtownroad wrote:
| Business advice rather than legal but... your customers are
| working with a company, not a person: the number of people at
| your company is immaterial. Lots of well-funded startups send
| everyone on vacation at Christmas for 2 weeks, and in some
| parts of the world it's very normal for people to take 4+ weeks
| off work in a row. Your focus should be on building a business
| that can operate while you're on vacation, or when something
| unexpected happens like hospitalisation: putting vacations into
| a contract is the wrong solution (and people will think you're
| bananas).
| chromatin wrote:
| I am just starting my small SaaS business and absolutely needed
| something like this. Favorite'ing this post and will return to it
| soon.
|
| 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.
| jakestein wrote:
| That's great to hear. Please let us know if we can help once
| you get started
| cm wrote:
| Congrats on the launch! Your site is loading now, albeit a bit
| slowly :)
| jakestein wrote:
| Thanks, we're working on it :)
| gnicholas wrote:
| What's the business model here? The agreements are free, so I'm
| guessing you make money on contract management? But small
| startups don't really need this (not enough to pay, at any rate),
| and larger startups do business with big entities that won't sign
| hyper-standardized contracts like these, for the most part.
|
| 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?
| bengarvey wrote:
| Pricing page is here: https://commonpaper.com/pricing
|
| 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.
| gnicholas wrote:
| Whoa, that's pricey! If I have a handful of customers, I'd
| definitely not want to be paying $600/yr for contract
| management. I'm not sure what "support" entails (you aren't
| offering legal services, I imagine), but this strikes me as
| really pricey. Good luck though!
| bengarvey wrote:
| Thanks! Not sure how many are a handful, but your first 5
| customers are free (no matter how many different contracts
| you send them). You're still welcome to download and use
| the contracts
| jakestein wrote:
| You're correct that we make money by charging for our software.
| It's free until you use it to close deals with more than 5
| customers, and free forever if you're just using it for NDAs.
|
| 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.
| gnicholas wrote:
| Free NDAs forever is great! I run a B2B SaaS/licensing
| business, and this pricing strikes me as really high. But
| perhaps others see the value differently. I can see how it
| would be useful to constrain negotiations to the various bits
| that your contracts allow. But given how much contracts vary,
| and how larger orgs want to use their paper, it seems like
| this is an uphill climb. And if my biggest, most important
| contracts are outside of your system, that makes the overall
| utility much lower for me.
|
| 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.
| jakestein wrote:
| That's totally fair, and it might be partially a function
| of price point. If, say we can help our customers close a
| bunch of deals at $20k each, that's very different than a
| company who has an average price point of $1k each. You're
| always welcome to use the agreements for free separate from
| our software.
|
| 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.
| gnicholas wrote:
| Can you help me understand how this platform, or the
| contracts alone, would help me close deals? I've never
| had a deal fall apart at this phase, or in a way that I
| could imagine this helping.
|
| 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.
| jakestein wrote:
| There are a few related things here:
|
| 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.
| darthvader2000 wrote:
| Great interface. Questions:
|
| > 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?
| jakestein wrote:
| Thanks for these questions, taking each in turn:
|
| > 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
| bengarvey wrote:
| Hi, one of the co-founders here!
|
| 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.
| intelVISA wrote:
| Nice, definitely a decent gap in the market for this. Site's slow
| as heck but the product's solid. Gl!!
| jakestein wrote:
| We were not ready for the huge amount of traffic from HN, but
| we've got everything sorted out now :) Thanks!
| davecyen wrote:
| Love what you're building here. How are you guys thinking about
| potentially integrating LLMs?
| bengarvey wrote:
| Co-founder here:
|
| How would you integrate an LLM into this?
| eterm wrote:
| What would you say to someone who is wondering if this is an
| attempt at a technical solution to a social problem?
| bengarvey wrote:
| CTO and Co-founder here.
|
| 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.
| gnicholas wrote:
| Are your founders lawyers, by chance? It seems like you
| understand the customer pain, but it's possible that creating
| a fix for this pain requires an intimate knowledge of how the
| legal community will react. As GP stated, this could be a
| social problem, and in that case it is one that is
| caused/perpetuated by lawyers. Or it could just be a matter
| of incentive misalignment.
|
| 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!).
| bengarvey wrote:
| My cofounder and I are not lawyers, but we have a great
| lawyer on our founding team and are advised by many more.
| https://commonpaper.com/committee/
| yz_coding wrote:
| Congrats on the launch! Common paper helped me customized my
| first contract and had the customer signed it within 3 days, all
| without having to pay for a lawyer. Fantastic product that helps
| founders.
| anon223345 wrote:
| This is one of those things that sounds cool at first but in
| reality, the sheer volume of edge cases because the real problem
|
| I bet this is gonna raise funding though
| jakestein wrote:
| I agree that the edge cases make this extremely challenging.
| That goes both for making the standard contracts and the
| software that manages them.
|
| 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.
___________________________________________________________________
(page generated 2023-05-23 23:00 UTC)