One thing I’ve always loved about working with lawyers is that they’re not deterred by longform prose. This is the full story of the evolution of Outlaw and the document format we invented and announced earlier this month, .vine. (And if you are deterred by longform prose, feel free to jump to the TLDR at the bottom; I won’t be offended.)
“Let’s make this a living, breathing document – everyone should contribute.”
It was late 2004, and I was just a few months into my first job out of college as a Business Analyst in the Technology division at American Express. My boss, Kelley, was big on collaboration, and she knew from the start that I was a coder disguised as a business guy, so she gave me free reign to tinker with tech and build whatever internal apps I could that might help improve the team’s operations and communications.
At the time, I was enamored with Wikipedia, or more accurately, wiki technology in general. I loved the notion of a web-based document that anyone (with the right permissions) could edit, and perhaps even more importantly, I was struck by the power of simple text syntax that non-technical users could easily learn. On a wiki, merely by putting words into [[double brackets]], the phrase inside, “double brackets”, becomes a link to another “article” — a separate web page in the wiki that anyone can edit. If the “double brackets” article already exists, it’s an immediately active link, and if not, the new page gets created as soon as the first user makes the first edit. This simple, intuitive content creation workflow was what had already enabled Wikipedia to accrue over 1 million articles and become the world’s most popular reference site within just 4 years of its 2001 launch.
So I developed a very simple, internal version of a wiki that would allow us to create living breathing documents on the corporate intranet. When my team of 10 got dissolved a year later due to a corporate reorg, I left to go work for a video game startup, and kicked off a side project in parallel. Coding on nights and weekends for the next 2-3 years, I built a create-your-own-wiki app using a Microsoft ASP.NET back-end, a mySQL database, and a Flash-based front-end which I used to visualize the network of interlinked articles.
By 2008 I was using my web app on a daily basis and sharing it with close friends and family. The use case that had the most “traction” (if we can call single-digit monthly active users traction, lol) was sharing and tweaking family recipes. I was close to pulling the trigger and launching this as my first startup attempt, but at the time, I couldn’t find any other nerds who got as excited as I did about text syntax and content structure, and I didn’t want to be a solo founder. I’d already gotten the startup bug bad though, so when my [now-]wife and I returned from a trip to Rome with the idea of building a travel recommendation engine, finding co-founders became a snap.
I shelved my wiki idea (and codebase) for a second time, not realizing that I’d still be continuing to work on this idea daily, just in a different way. Over the next 4 years, just like any startup CEO, I negotiated and signed hundreds of contracts: fundraising, employment, board resolutions, NDAs, partnerships, sales, you name it. We had counsel, but we were still on a startup budget, so I became pretty adept at dealing in general business legalese — and at executing the legal contracting process and lifecycle — without incurring legal fees.
Contracts have many of the same requirements as wikis when it comes to cross-document linking (they just call these ancillary documents “Appendices” or “Exhibits” or “Schedules”), but they’re far more functionally demanding on numerous other fronts. Wikis and other web publishing platforms can get away with using HTML as their underlying data structure, with rudimentary syntax like markdown achieving the “good enough” mark for formatting, but contracts demand a full dedicated word processor.
The incumbent choice for contract drafting in 2012 was, of course, still Microsoft Word, but again I was struck by a syntax convention involving square brackets — single ones this time — for two distinct functions. First, they denoted temporary values that would need to be filled in later, aka fields or variables, for everything from a party’s [Full Name] to a sales contract’s [Purchase Price]. Second, they would demarcate sentences or entire paragraphs that could be conditionally included [, depending on the context and scenario]. Unlike wikis, though, these bracketed words or sentences weren’t tracked anywhere or magically transformed into links; Word isn’t that smart. Instead, these elements just sat there waiting for someone involved in the contracting process to [hopefully] find them and manually fill them in with correct values prior to signing.
As I noticed this convention on every single one of the hundreds of contracts I touched, I had the same mental reaction: This is the wrong tool for this job. We can do better. I’d frequently even get distracted by this thought while attempting to review a contract, as my mind would start to wander and fantasize about reviving my wiki project to tackle some of these challenges, instead of focusing on the substance of what I was reading. So after having that visceral reaction hundreds of times, I knew what my next venture would be by the time we exited. But I was also burnt out from my first startup lifecycle and got sucked into big tech for a few years to recoup energy and savings for round two.
When I met Dan in 2015 and we started tinkering on projects together, he was still doing a lot of freelance design work, which served as extensive user research for counterparties, aka contract recipients. Turns out that for the 99.9% of us who aren’t trained lawyers (or startup founders), receiving an email that says, “Here’s the contract, please review and sign at your convenience,” then clicking a link or opening an attachment only to be hit with an immediate wall of incomprehensible legalese, SUCKS.
So we set out to prototype an end-to-end user experience whereby both parties could draft, send, negotiate and sign a contract lightning fast, in plain English (this aspect would later become Outlaw’s unique Overviews feature), from their phones — no Word required, and no DocuSign either, for that matter. This time, I built an iOS app in Swift 2, and after a few months we had ourselves the world’s nerdiest and most annoying party trick. We’d walk up to friends and go, “Hey, watch us generate and sign a Mutual NDA with each other in 30 seconds!” Good times.
Our “mobile-first” approach turned out to be wonderfully formative in cementing our commitment to creating a seamless, consumer-grade user experience for contracts, but in reality, we also knew that we’d need a web app if we wanted to achieve any adoption whatsoever. I happily scrapped my entire codebase yet again, incorporated Outlaw in early 2017, and started fresh. This time, finally, I was building for real, and for eventual scale. I chose a tech stack far more conscientiously this time, selecting technologies that were a balance of modern, yet proven.
Firebase was a groundbreaking real-time, noSQL database enabling JSON-based document storage, and had been acquired by Google in 2014 and rolled into Google Cloud Platform. React was an open-source library developed and used by Facebook, and had already quickly become the standard for front-end web apps. Node and Express provided an extremely lightweight and robust web-server/API layer and, importantly, enabled a single, unified data model to be defined in JavaScript and shared between front-end and back-end. Collectively, this was aptly dubbed the FERN stack — another organic metaphor — and was natively scalable, cloud-based, built on open standards, and dirt cheap to host. (Incidentally, while I’m speaking in the past tense here because these decisions were made six years ago, this stack remains a top-tier choice today, as all of the component technologies and developer communities have continued to flourish).
Fast-forward through 4 years of rapid product development and iteration as we pushed Outlaw to market. In early 2021, I received a cryptic email from the VP of Corporate Development at a company called Filevine, wanting to talk about a potential “strategic transaction.” Cain and I hit it off immediately, and we teed up a full demo for a few days later with the CEO. As it became clear to them within minutes that we’d built our own word processor and document format from scratch, Ryan paused, and then said something I’ll never forget: “Gosh, it’s almost like you’re the yin to our yang!”
I’d quickly discover in the ensuing months that Ryan’s down-to-earth leadership style is punctuated by a superpower to build trust disarmingly fast by sharing vulnerability like this. In truth, I didn’t know exactly what he meant at the time, because we were wrapped up in the CLM space, and Filevine was not a competitor. My sole focus in these early discussions — as with any sales process — was to advance to the next meeting, and that was clearly in the cards.
But as we conducted mutual diligence on one another and I learned about our prospective acquirer, I came to understand the full prescience of Ryan’s statement. Filevine was an eminently configurable database, enabling its customers, who were mostly law firms, to manage and track the myriad pieces of data involved in a wide range of legal matters. A document generator was included, but it followed the “mail merge” paradigm of the early 2000’s, resulting in disconnected exports of relevant data into static Microsoft Word documents. While rudimentary, that was the industry standard, so it still met law firm clients’ expectations, but it propagated all the same tedium, human error, and versioning hell that Outlaw was already solving in the contract space. Ryan saw from the very start that getting Outlaw’s document engine seamlessly integrated into Filevine would be a sea change for customers. Having formerly run a practice himself and dealt with thousands of legal docs using Microsoft Word, he’d had that same visceral reaction: We can do better.
My top consideration (alongside price) in contemplating the sale of my second startup was an existential one. Perhaps nothing lasts forever, but after years of being unable to look more than 3-6 months down the line, the prospect of guaranteeing our existence for 5+ years still felt like a leap forward. We quickly discovered that buyer and seller incentives were fully aligned in that respect, and baked two key terms into the transaction: Outlaw would live on and continue to operate in the CLM space, and we would continue R&D on the underlying document engine in order to integrate it into Filevine.
Another 18 months of both parties executing on these promises in good faith brings us to today, and to the TLDR I promised at the start of this article. Our announcement and media response have sparked some lively internet discourse, which is healthy, but also largely uninformed, so I want to clarify a few things.
Outlaw powers .vine
This is not vaporware, and it’s not “alpha” or “experimental” technology. The document format that we’ve packaged as .vine and made available to Filevine customers (and soon beyond, stay tuned!) is rooted in Outlaw’s tech. The earliest R&D on this organic, dynamic approach to structured content began nearly 20 years ago, with the current iteration of this technology actively commercialized over the last six. In that time, thousands of Outlaw customers have created, negotiated and executed millions of contracts using our legal drafting engine. It’s real, and it works.
Open and standard and portable, oh my!
Microsoft first released Word with a binary, closed, opaque .doc format in 1983, and didn’t move to the XML-based .docx format until 2003, twenty years later. After that, it still took them another five years to publish Open Office XML Standards in 2008 and finally begin enabling other companies and services to read and write Word documents.
The .vine format is already JSON-based (which, like XML, is plain text, not binary), so we’re already starting from a substantially more open and standards-oriented foundation, and we expect to publish an open specification for .vine [by the end of [2023]]. See what I did there with the brackets?
In truth, I don’t yet know what our timing will be on taking official steps to open or standardize the format, but I do know they’re coming. In fact, part of my motivation for sharing the full 20-year history of this invention is to demonstrate that I’ve deeply felt the pain of being tethered to closed, proprietary technologies. I’ve personally been burned twice already, first with Adobe’s Flash, and then with Apple’s Swift, forcing me to throw thousands of hours of my own effort out the window. And that’s just a single engineer’s time; when multiplied by hundreds or thousands of legal professionals at an organization building document and template libraries, that walled garden imprisonment is not something I’d wish or impose on any organization.
So yes, we’re absolutely committed to making .vine open in the near future. That said, getting too far into the weeds about specifications and standards right now is missing the mark. The far more operative issue in the nearterm, especially for natively cloud-based services like Filevine and Outlaw, is not one of standards; it’s one of portability. Organizations need confidence that in the event of a vendor force majeure (i.e., a company shutdown), their data — which in this case, means their template and document libraries — will still be easily accessible.
On that front, I’m happy to share that we are making a firm commitment: .vine documents and templates will be exportable in bulk off-platform as files of any of our three supported formats — .vine, .docx, or .pdf — by the end of Q1 2023.
Microsoft Word is dead, long live Microsoft Word
Finally, while I wholeheartedly share Ryan’s belief that “.vine will [eventually] become the new standard in the legal industry,” I also think it ought to be self-evident that a bold prediction like that in a press release is troll bait, so any dialogue fixated on that prediction is, again, missing the point. “Standard” in that context obviously means “gold standard” — the best, most powerful choice, not the only choice. But more importantly, dethroning any player in any industry who’s had monopoly status for forty years is always going to be a multi-decade endeavor. Only time will tell whether we’re right.
In the meantime, for the avoidance of doubt, .vine is fully interoperable with Microsoft Word. Documents can be exported from .vine to .docx via a single click with 100% fidelity, and .docx files can also be uploaded to Outlaw (and to Filevine Document Assembly), making the template migration process seamless. We’re also working on a Word plugin, estimated to launch within 6 months, which will only help to connect the dots even better for our customers.
We know that the legal world is still addicted to Word; failing to acknowledge and incorporate that reality into our distribution strategy would be categorically insane. And just for the record, as an inventor and engineer myself, I have deep respect and admiration for any piece of software that can stay on top for so long. But Microsoft Word’s original purpose, its DNA, was to replace typewriters as personal computing became ubiquitous in the 1980’s; it wasn’t designed for the advanced, connected and organic demands of millions of legal professionals today. For that, now there’s .vine. We can do better.
