How We Built a Legal Tech Platform That Took a $7,000 Contract Down to Hours
Ionio partnered with Standard Draft to build a legal tech platform where both sides of a
contract draft, negotiate and sign in one place, working from a shared neutral form rather
than a fight over whose template wins. A routine enterprise contract went from
roughly 31 days down to about six hours.
The raw material was one corporate lawyer's working knowledge. Ryan Samii was a big law
corporate lawyer before he founded Standard Draft, and he knew which decisions in an NDA
actually get argued and which parts nobody has ever changed. We encoded that into a
templating engine and built the platform around it. Building it is what took
him from practising lawyer to Hebbia, and then to Head of Product Innovation at Harvey
($11B), the largest legal AI company in the world.
Ryan Samii, Founder of Standard Draft. Now Head of Product Innovation at Harvey.
On how we started
“You brought a willingness to not just go in and start coding, but really gain a deep appreciation of what we're all trying to do here.”
On the architecture
“Your approach was really sharp. People were able to gain confidence, like, yeah, this actually is a really smart way to build this.”
On the stack we chose
“You weren't trying to go with some funky languages or tech stacks, so that you could empower me to bring additional talent down the road.”
On launch support
“Ionio didn't disappear after the MVP was built. They continued to work with us to fix bugs and make improvements based on user feedback.”
On the working relationship
“It felt like there were partners around the table with me, not just people carrying out discrete tasks.”
On building with a first-time founder
“Particularly for someone like me, a first-time founder, a non-technical founder, having that kind of partnership around the table has been instrumental.”
The Expensive Problem
Two companies want to work together. Before anything else happens, their lawyers have to
agree on a contract.
Here is how that goes. One side sends the contract as a Word document. The other side reads
it, highlights what they want changed, and sends it back with comments. Someone adds a
clause. Someone narrows a definition. The file crosses again, and every time it lands
a lawyer has to read the whole thing to find out what moved.
Put fifteen lawyers on each side of that exchange and a routine contract takes
31 days to close. Complex deals take longer.
The Round Trip
One Routine Contract
Day 1Draft sent
Day 9Marked up, returned
Day 18Redrafted, sent again
Day 31Agreed
One document, four crossings, a month gone.
Most of that time has nothing to do with legal judgment. Every negotiation opens with an
argument about whose template to use, which decides nothing about the deal and only settles
who gets to draft from their own preferred language. After that both sides write in prose,
with no shared reference for what a normal version of a clause looks like, so they build it
from scratch. Then they do it again on the next deal.
The tooling never helped, because every legal product ever built serves one
side. Yours helps your team draft faster. Theirs does the same in the opposite
direction. You can double your own speed and the negotiation still takes a month, because the
bottleneck was never one side working slowly. It was the document bouncing between two.
The Bridge That Never Meets
Every Gain Lands On One Side
2×Faster on your side
2×Faster on their side
0×Faster across the handoff
Every tool makes a half faster. None of it reaches the middle.
The cost of that lands on the business, not the legal department. Reviewing and processing one
basic everyday contract runs to at least $7,000, and complex or multi-party
agreements cost far more. It scales with growth, since more deals mean more contracts and more
hours spent reading them. Organisations spend hundreds of thousands of dollars a year here,
and 89% of those surveyed still don't call their contracting process efficient. Every day the
paperwork takes is a day the revenue behind it has not arrived.
Standard Draft moved this from a month of document ping-pong into a workflow measured in hours.
Both sides work on the same platform, from the same neutral form. Clauses get configured
through an interface rather than rewritten in prose, and the other party can see exactly what
you changed and how the draft differs from where you both started. That is a
>10x acceleration on the step that gates every agreement a company signs.
The Philosophy
Domain Expertise, Turned Into the Intelligence Layer for Software
We run every prospective build through the same check. We call it the monetisation test.
Someone holds deep expertise in a domain. They already have distribution into the market that
needs it. And somewhere in their work sits a complex task they repeat constantly, solving it
the same way each time. Put a software layer over those three and
a service becomes something that earns without the expert in the room.
Ryan had all three, which is why this project was worth doing:
The Monetisation Test
Three in, one layer, output that keeps running
Domain Expertise
Years as a corporate lawyer on mergers and acquisitions, with a working knowledge of which contract points get argued and what the reasonable positions on each one are.
Distribution
A network across the legal space, and direct access to the people who would use the product.
Repetitive Task
Drafting and negotiating NDAs for enterprise counterparties, over and over, at $7,000 a contract.
What made it encodable was the repetition. After enough transactions Ryan knew the shape of a
contract before he opened the document, and a pattern that stable can be written down
carefully enough to hand to someone with no legal training at all.
The expertise stops being a service billed by the hour and becomes a product that earns while the expert sleeps.
So Standard Draft is not a faster editor and not an assistant sitting beside a lawyer. It is
one experienced corporate lawyer's working knowledge, encoded into templates and
configuration rules, so anyone can arrive at the contract he would have drafted.
We have since given this idea a name and built a practice around it. Prescriptive Intelligence
is the same move applied to platforms that already exist: encode the domain SOPs, run them
against live data, and output the exact next action rather than another dashboard. Standard
Draft was us doing it before we had the language for it.
Why This Was Hard
We started building this in 2022. Standard Draft was our first legal product, and
most of what made it difficult had nothing to do with writing code.
Enterprise Contract Negotiation Is a Closed World
Domain
The kind of negotiation Standard Draft was built for happens between legal teams at
companies large enough to have them, behind closed doors, under privilege. None of it is
written down anywhere you can go and read it. So Ryan taught us. How a mutual NDA differs
from a unilateral one, why the definition of confidential information gets fought over,
what a markup is and who produces it, and what a lawyer expects to see on screen before
they will trust software with a live deal. We spent real weeks on this before
anyone drew a wireframe.
What this meantLearn the work first. Wireframes came after.
Two Parties, One Live Document
Complex
A contract on Standard Draft is open to both sides at once, and each of them needs to
understand it from the opposite direction. That meant an engine rendering your changes,
the counterparty's changes, the clean contract, the markup, and the difference between
the current draft and the form you both started from. All of those views had to
agree with each other, however many rounds the document had been through.
What this meantFive views of one document, never disagreeing.
The Templating Engine
Core
Contracts are not hardcoded into Standard Draft. Every contract type lives as a template,
and the platform assembles the document from it at runtime. This was the hardest
thing we built. An NDA runs to eight sections, with sub-sections inside them and
a third layer of nesting below that. Click an option on the left and the right text has to
appear, move or disappear, at any depth, in any order a lawyer happens to work in. There
was no AI to lean on in 2022 and nothing published on how to do it. We took the work on
without knowing whether it was solvable.
What this meantWe started without knowing it could be done.
Compliance Was a Build Constraint, Not a Checkbox
Regulated
Legal is a regulated industry and the documents moving through this platform were live
commercial agreements under negotiation. Data handling, retention, access control and
audit trails all had to be designed in from the first architecture decision. A
compliance posture cannot be retrofitted onto a legal platform that is already
running. We built for SOC 2 and GDPR readiness from the start, because a product
that fails procurement never reaches a user regardless of how good it is.
What this meantArchitected for procurement from day one.
Lawyers Do Not Give Second Chances
Audience
Ryan was blunt about this early. With a consumer product a shaky first version still gets
another look. With lawyers as the target user, the product has to be legitimate
before anyone will touch it. That set the bar for everything we shipped. No rough
edges we planned to fix later, and no features that worked most of the time.
What this meantNo rough edges. No features that mostly worked.
"The engineering was the tractable part. The hard part was a closed profession, a
document two sides had to trust, and a bar that had to be cleared on the first try."
Product Walkthrough
The Platform in Action
An NDA that would normally take a month of Word documents and email, built, marked up and
sent to the other side in a single sitting. Here is Standard Draft from the inside.
The Product
Draft, negotiate, review, sign
Standard Draft sits between two companies rather than serving one of them. One side proposes
a contract, both sides work the same document, and it moves from drafting through to
signature without leaving the platform.
01 / Create
Three steps to a working contract
Creating a contract takes three screens. The platform states plainly that it is a legal
technology company and not a law firm, then asks which form you want and what to call the
document. The form selection is where the templating engine surfaces to the user: a
short-form NDA built for everyday commercial use, a long-form built for M&A and financings
with the full range of configurability, and room for the contract types that were
coming next.
Step 1. Terms and disclaimer.
Step 2. Short-form or long-form NDA.
Step 3. Name the document.
02 / Draft
A contract that already knows its own shape
The contract opens pre-populated with sensible defaults, split down the middle. Configuration
on the left, the live agreement on the right, and the eight sections of an NDA laid across
the top from Confidential Information through to Miscellaneous. The badge tracks where you
are: drafting, stage one of three.
Nobody hands over a template and nobody starts from a blank page.
03 / Configure
Decisions on the left, contract on the right
Open a section and it breaks into the points that are actually negotiable. Under the
definition of Confidential Information sit the timing of disclosure, the form it has to take,
whether it must be marked as confidential to qualify, and how to treat derived material.
Change one and the agreement rewrites itself beside you, new language
underlined in blue against the neutral form everyone started from. The card marks itself
Edited by you and carries a comment thread, so the other side can see what moved and argue
about it in place rather than over email.
04 / Guardrails
The form holds its own boundaries
Not everything is open. The short-form NDA locks the sections it was not built to configure
and says so in place, pointing you to the long form if you need them. What stays
configurable, like the term or the governing law, opens on demand.
That is the templating engine doing its job. A contract here is a structured object
with rules attached, not a document that will let you write something incoherent.
05 / Reuse
Save the decisions, not just the document
Once a set of positions is settled, it can be saved as a template and pulled into the next
contract of the same type. A legal team stops re-deciding the same dozen points on every deal
and starts from its own house standard.
06 / Send
Hand it to the other side
Every section checked off, and the contract goes to the counterparty. You enter their side
and yours separately, and either party can add viewers from their own team.
This is the part that makes Standard Draft a bridge rather than another one-sided
tool. The counterparty opens the same contract in their own account, sees the same
version chain, and can read the draft against the neutral form it started from. No
attachment, no reconciling two copies of a Word file, no reading the whole agreement to work
out what changed.
The Solution
What We Built
Ionio owned the full arc: product strategy, wireframes, UI and UX, architecture, the build,
deployment, and the handover at the end. Five systems carry the product.
01
The Templating Engine
Every contract type lives as a template that describes its sections, its sub-sections, the
third layer of nesting below those, which configurable point governs which passage of text,
and what happens to the surrounding language when that point changes. Get it right and
a new contract type becomes an authoring job rather than an engineering one.
Write the template, load it in, and the platform can negotiate it. That is what turned
Standard Draft from an NDA tool into a platform, and what made the roadmap into M&A
agreements possible at all.
One file, and every clause grows from it.
02
The Contract Designer
Ryan told us in the first wireframing session that lawyers will not work inside a
questionnaire. They need the full text of what they are agreeing to in front of them
while they agree to it. So the configuration panel and the live contract sit
together on one screen and stay in step, with the affected language marked as each decision
lands. Getting that correct at every depth of the template, in every combination a lawyer
might click through, took months.
Lawyers would not answer questions about a document they could not see.
03
The Comparison Engine
The engine renders a contract five ways: clean, marked up, your changes, the counterparty's
changes, and the difference between the current draft and the neutral form.
That last view is what makes the negotiation honest, because nobody has to
read the whole agreement hunting for what moved. Alongside it, the version history chain
records every round and who did what, and any clause can be opened for background on the
standard positions available, then changed or reinstated in a single click.
Turn the dial to the fifth setting and the argument ends.
04
Document Fidelity
A contract that leaves the platform has to be indistinguishable from the one on screen. Legal
documents carry meaning in their structure, and a numbering scheme that shifts or an
indent that collapses is not a cosmetic problem when the document is about to be
signed. We built the export path to hold every style exactly, so the file a lawyer
opens is the file they approved.
The file a lawyer opens is the file they approved.
05
The AI Layer
Once the platform was running we added a chatbot over the live contract, built with retrieval
augmented generation and embeddings so the model answered from the agreement in front
of the user rather than from general knowledge. This was the GPT-3.5 era, when the
API had barely shipped and nobody had settled how to do this well. It let a user ask what a
provision meant in plain terms, understand why the other side had requested a change, and
draft common contracts from ordinary language. For a product arguing that contract decisions
should be legible, that was the right place to put AI.
Not what the model knows. What this contract says.
Internal Infrastructure
Technical Infrastructure
The platform runs on a deliberately conventional stack. Ryan was going to hire engineers of his
own eventually, and every choice had to be one he could hire into.
Frontend
ReactJS
Carries the split-screen contract designer, the most demanding surface in the product.
Every selection redraws the document beside it without a page reload and without
losing the user's place in a long agreement.
Backend
Node.js and Express
Runs template resolution, the version history chain and the comparison logic. Mature,
thoroughly documented, and staffable anywhere in the world.
AI Layer
LLMs, embeddings and RAG
Powers the contract chatbot. Contract text is embedded and retrieved so
answers come from the agreement actually in front of the user.
Cloud
AWS and Docker
Every component containerised and deployed to AWS. Consistent environments across the
team and capacity that grows without re-architecting.
Signing
DocuSign
A contract negotiated on the platform gets signed from the platform,
rather than exported into a separate process somewhere else.
Compliance
SOC 2 and GDPR ready
Architected for readiness from the first decision, because
legal teams put software through procurement before they put a contract into
it.
The Results
The Business Impact
31 Days to About Six Hours
A routine enterprise contract took roughly 31 days to draft and negotiate. On Standard Draft
it took a working day at most, at several times lower cost. That came from
deleting the parts of the process that were never legal work: the argument over whose
template starts the deal, the read-through of a returned document to find what moved, the
reconstruction of which version anyone is looking at.
What one contract used to cost
31 daysTo draft and negotiate a routine enterprise contract
$7,000To review and process one basic everyday contract
89%Of legal teams surveyed do not call their process efficient
On Standard DraftAbout six hoursA working day at most, at several times lower cost
Traction Inside the Legal Industry
Standard Draft went into private beta with real agreements moving through it, and
it was taken seriously by large names in the legal industry. For a product
whose first users are practising lawyers, that is the hard part. Ryan set the bar himself
when he told us that with lawyers as the target user the product has to be legitimate before
anyone will touch it, and the platform cleared it.
The Founder Walked Into the Best Job in Legal AI
Ryan started this project as a corporate lawyer. Nothing on his record said technology. By
the time the platform was live he had specified, built and shipped a legal AI
product, and could sit with engineers and talk about how it worked.
The legal industry had almost nobody like that, and it was about to need a great many of
them.
He joined Hebbia as their first lawyer, hired to build a legal vertical from nothing. From
there he went to Harvey as Head of Product Innovation.
Harvey is the largest legal AI company in the world. In March 2026 it raised $200 million
co-led by GIC and Sequoia at an $11 billion valuation, bringing total funding past $1.2
billion across ten rounds in under four years. More than 100,000 lawyers use it, across
1,300 organisations in 60 countries, including the majority of the AmLaw 100.
$11BValuation, March 2026
100,000+Lawyers using it
1,300Organisations
60Countries
Lawyers do not get hired to run legal AI. Lawyers who have built it do.
That is the outcome worth pointing at. Standard Draft was never acquired, and we
would rather say so than dress up a number. What the two years actually produced was
a person the entire legal AI industry wanted, and the reason they wanted him is sitting in
this case study. He could point at a real platform, explain every decision inside it, and
prove he had done the thing rather than talked about it.
How We Build
Code That Transfers
Partway through the build, Ryan commissioned a third-party audit of our work. The reviewer came
in with a CTO-level brief: work out how they would have built Standard Draft, then
compare that against how we actually had.
The point was not doubt. He knew he would be hiring engineers of his own eventually, and he
wanted to know that when that day came they could pick the codebase up and run with
it.
The real test of a handover is what happens after it.
What came back was that we had used ordinary technology in ordinary ways.
React, Node, nothing clever for the sake of it. A new engineer could open the repository and
recognise everything in it. That is the whole reason we choose stacks the way we do, because a
client who can only run their product with us in the room does not really own it.
More founders should do this while a build is still in progress rather than after.
Project Roadmap
Our Approach
Two years, four phases, and a long pause in the middle that turned out to be the right
call.
Execution Timeline · 2022 to 2024
BlueprintValidation pauseBuildBeta & handover
The gap between the first two bars is the pause that saved the build.
Phase 1 · Blueprint and Micro POC
2022
Wireframes built out from Ryan's hand drawings and Google Drawings files
Full UI and UX mockups in Figma, every screen drawn by hand over roughly two months
A micro POC to make a working piece of the platform real
Estimated at three to four weeks. Took considerably longer.
The micro POC exists because of a gap Ryan named directly. He could see we were polished on
calls, and that told him nothing about whether we could build. So we took
the early wireframes and made a piece of the thing work. It was one of the first
engagements where we did this, and it is now standard practice on every project we run.
Phase 2 · Validation Pause
2022
Ryan went back out to users to pressure-test the concept
A third-party audit of the codebase and the stack
Scope narrowed to how much product was actually needed before production code
From our side this looked like a delay. In hindsight it was
the most valuable stretch in the schedule. Once a build starts it develops
its own momentum, and questions that should have been settled beforehand end up getting
answered under pressure.
Phase 3 · The Build
2022 to 2023
Templating engine first, because everything else depended on it
Contract designer, with change state tracked at any depth of the template
Comparison engine rendering five contract views, plus the version history chain
Document fidelity work to hold every style out to Word
DocuSign integration so signature happened inside the platform
A little over a year, with a team of four
Phase 4 · Private Beta, AI Layer and Handover
2023 to 2024
Users onboarded individually by Ryan rather than a public launch
Bugs surfaced under real use, some fixed the same night
RAG chatbot added over the live contract text
Platform handed over, Standard Draft's CTO and technical staff onboarded
Ryan deliberately avoided opening it up. He watched how a small number of users actually
used the product rather than asking whether they liked it, which meant
the things that broke broke in front of people who mattered.
Retrospective
What We Learned
Standard Draft asked two sets of lawyers to abandon a habit the profession has held for
decades. The engineering turned out to be the tractable part.
I.
You cannot architect a domain you have not learned
We spent real weeks learning enterprise contract negotiation before designing anything.
Every good decision in the product traces back to that period, and the
alternative was building clean software for a process we had only imagined.
II.
What you skip in design, you pay for in build
We mapped most of the platform properly during wireframing and left a handful of edge cases
for later. What happens if the sender wants the contract back after sending it. What
happens if the recipient adds a viewer on their side. Those questions cost nothing on a
whiteboard, and they came back at roughly double the cost once we were building, because
now they had to be answered and implemented at the same time against code that already
assumed something else. A four-month estimate on that stretch became eight.
III.
Boring technology is a feature
We used a conventional stack, and it was the first thing the third-party audit approved.
Unusual technology is a tax the client pays after you leave, in the form of
a codebase only you can staff.
IV.
Adoption is a harder problem than architecture
Standard Draft was not making an existing workflow faster. It was asking a profession to
start somewhere new. No amount of product quality shortens that, because
the competitor is not another platform, it is the way people already work.
The playbook still runs.
The lawyer moved on.
That is the whole point of encoding expertise. Someone spends a decade learning to make a
specific call well, and we build the system that makes it at scale, for people who never
met them. Standard Draft did it with one corporate lawyer's knowledge of how enterprise
contracts get argued. Prescriptive Intelligence does the same on platforms that already
exist, encoding the SOPs and returning the next action instead of another dashboard.
Ryan brought expertise worth encoding. We built the platform that carried it, handed it
over, and watched what it did for the person who had been selling it by the hour.
How We Operate
01 // Integration
We embed with your technical team. The work you just read represents how we operate. We build production systems that connect into your existing architecture, and transfer the knowledge so you own what we build.
02 // Acceleration
We do not start from zero. The tooling we have developed across our engagements, the pipelines, the agent frameworks, the eval systems, accelerates every project we take on. You are not paying us to learn on your time.
03 // Experience
We know what works. We have been building AI systems for a decade. We shipped architectures before they became mainstream, and we know the pitfalls because we have made the mistakes already.
When to Talk to Us
You hold deep expertise in a domain, the way Ryan did in enterprise contract negotiation, and you can see the next version of your category is a product, not more hands.
You want a partner who understands the business model as well as the technology, not a dev shop that only builds what you specify.
When We're Not a Fit
You want a chatbot for your dashboard, AI for the press release, or features a foundation model will commoditize in six months.
We will tell you that directly.
Next Step
Let's See If There's a Fit
30 minutes. No deck. We will talk through your challenge, share some relevant work, and
see if it makes sense to work together. Or honestly, just grab coffee and chat, no agenda
needed.
.jpeg)
