What Is a Contract, Really?

What Is a Contract, Really?

Adam Schlossman
6 min read

On the messy human process of collaboration

If you ask most people what a contract is, they'll point at the document. The thing that gets signed. The PDF, the Word doc, the page with the signature line at the bottom. That's what people mean when they say contracting. Reviewing the contract. Sending the contract. Signing the contract.

But think about what had to happen before that document existed.

Two parties had to find each other. Someone had to reach out. The other side had to respond, or not respond, or respond three weeks later. They had to decide they were even interested. An NDA had to get signed before anyone could share details. Then a rate had to get discussed. Then a counter. Then deliverables. Then exclusivity. Then a hundred other small things, traded back and forth across email, DMs, and spreadsheets, sometimes with an agent in the middle, sometimes with a manager, sometimes with a legal team copied at the end.

Only then does someone open a Word doc.

By the time there's a contract to review, weeks of work have already happened. None of that work is in the document. None of it ever will be.

So when people say contracting, they mean the last step. The document. The first 95% of the work, the part that actually decides what the document says, has been sitting somewhere else the whole time.

There is infrastructure for the first 95%. Email. Spreadsheets. PDFs flying back and forth. Notes in someone's head. The work is getting done. It's just getting done on tools that weren't built for it. There's no centralized place where the negotiation lives. No system that captures what was asked for and what got traded away. No way to take advantage of the work that people are already doing.

The information is everywhere, but it doesn't add up to anything.

I lived this at Religion of Sports, Delta Rae, Akin Gump, and the FTC. Manual data entry. Just following up. Reconstructing what was agreed to two weeks ago. Hunting for AGREEMENT_FINAL_v4 across email threads and Google Drives. Four industries. Same problem.

Two and a half years building Basa. One question kept coming back: what actually is a contract?

A contract is structured data derived from a messy human process.

The deal is the process. The document is one step in it.

Where the existing tools sit.

Every tool in this space starts at the document. DocuSign starts when you hand it something to sign. Ironclad manages the document through its lifecycle. Evisort uses AI to extract information from contracts after the fact. Harvey gives lawyers a smarter way to work with the document in front of them.

All of them are useful. None of them are wrong. They're just all working on the part of the process that comes after the hard work is done. The outreach, the negotiation, the back-and-forth that determined what the document actually says, that all happened somewhere else, on infrastructure those tools were never built to touch.

If you're only solving the document, you've solved the lawyer's problem. You haven't solved the problem of how long it took to get to a document worth reviewing.

Term-based, not document-based.

This is the architectural choice my co-founder Ryan and I keep coming back to.

Every other tool in this space is document-based. The contract is the unit. Everything orients around the document: managing it, signing it, storing it, extracting from it after the fact. The intelligence about the deal never makes it into the document. Who asked for what, what got negotiated away, what the history with this counterparty looks like. None of it. Some of it gets reconstructed later by AI reading the PDF. Most of it is gone.

Basa is term-based. The unit is the term, not the document. We capture each term where it actually gets negotiated, during the back-and-forth, before any document exists, with the context of how it got there. The rate isn't just $10,000. It's $10,000 negotiated down from $15,000, for this creator, in this category, where this exclusivity term held and that one didn't. The contract still gets generated at the end. Your legal team's templates, your legal team's language, signed through DocuSign or Ironclad or whatever you use today. That doesn't change. But the terms behind the document stay alive, queryable, and connected to everything that came before and after.

Ryan is the one architecting this. He's the one deciding what becomes a structured field in the data model and what stays freehand text. He's the one mapping out how a term moves through outreach, negotiation, redline, signature, and amendment. The architectural choice is his, and it's the choice that everything else in the platform sits on top of.

Two teams, one document, one set of frustrations.

Every contract has two kinds of terms. Business terms: rate, deliverables, scope, exclusivity. Those are commercial decisions, owned by the deal team. Legal terms: confidentiality, liability, indemnification. Those are policy decisions, owned by legal. They live in the same Word doc, but they belong to different people.

In organizations, the document is the only place those terms exist together, which means as soon as a contract goes to legal, the deal team is on legal's calendar, not their own. The deal team sits and waits. Legal opens a queue full of small deals with basic redlines they've resolved a hundred times before. Both teams are frustrated for the same reason: the architecture doesn't separate what belongs to each of them.

Term-based architecture lets it. Legal sets parameters once. Which terms are fixed, which are negotiable, which can be picked from a library of approved options. The deal team operates inside those parameters without touching legal's calendar. The $500 creator deal doesn't need a lawyer. The $10 million partnership does. The right infrastructure knows the difference.

Your data. Generated by your teams. Currently dying at the edge of whoever collected it.

Your New York team's rate negotiation with a creator in LA. Your London office's deal history across EMEA. The agency you worked with in São Paulo last quarter, negotiating on your behalf. Different cities, different offices, sometimes different agencies, all generating data about your business that currently lives in someone's inbox or someone's PDF folder.

A new team member inherits nothing because nothing was structured to be inherited.

Most analytics in the influencer space are built off the APIs of the social platforms. The platforms can tell you what the content did. They can't tell you what the deal looked like. They don't have that information, because the deal was negotiated somewhere else, in private, between two parties who never shared it with anyone. The terms (rate, usage rights, exclusivity windows, kill clauses) exist only in the contracts. And the contracts are PDFs.

The data that matters for understanding your own business is data you generated yourselves and then locked in unsearchable files. Term-based architecture makes it queryable. What's the gap between initial ask and final agreed rate by category? Which usage rights show up in your best-performing campaigns? What does your full history with a counterparty look like before you start a new negotiation? That information already exists. It's already yours. It just hasn't been captured in a form where you can use it.

The complexity is the human behavior underneath the technology.

Two parties with their own incentives, their own information, their own constraints, trying to reach an agreement. The agent who goes quiet for a week is managing a client with cold feet. The brand pushing hard on exclusivity has a competitor relationship they can't talk about yet. The creator who hasn't signed the NDA has been burned before and wants their manager to review it first.

None of that is in the document. None of it ever will be. And no technology is going to navigate it for you.

Technology can take care of the rest. The filing, the following up, the copying between systems, the searching for what was agreed to six months ago. That's the infrastructure tax. Negative-value work people do because the systems leave them no choice. If you're spending 30% of your time on it, that's 30% you're not spending on the work that actually requires being human.

The work that actually requires being human is different. Reading between the lines. Deciding whether a rate reflects the market or reflects desperation. Building the relationship that makes the next deal easier. That work can't be automated without losing something real.

Basa doesn't have AI in the product yet. The infrastructure problem doesn't require AI to solve. It requires rethinking what a contract is, where the deal data actually lives, and what gets captured versus what gets lost.

The document is the last step. Everything that determines what it says happened somewhere else. We’re building for that.