Data as of Aug 25, 2026 · Based on 323 AI responses from ChatGPT Search and Google AI Mode · See how Parse measures this
Brands AI recommends here
Named in 21% of answers
Named in 17% of answers
Named in 15% of answers
Named in 15% of answers
Creating the first set of standard legal templates as a startup's first General Counsel is a foundational balancing act: you need enough protection to keep the company safe, but not so much friction that you choke business velocity. Here is a structured, step-by-step approach to building your initial suite of legal…
Creating the first set of standard legal templates as a startup's first General Counsel is a foundational balancing act: you need enough protection to keep the company safe, but not so much friction that you choke business velocity.
Here is a structured, step-by-step approach to building your initial suite of legal templates:
- Meet with founders, sales leads, and product heads to identify what contracts are *actually* being signed right now or are urgently needed next week.
- Prioritize based on immediate revenue generation and operational exposure (e.g., if you are enterprise B2B, you need a Master Services Agreement; if you are hiring, you need an employment/contractor suite).
- Tier 1 (Immediate/Day 1): NDA (Mutual and Unilateral), Proprietary Information and Inventions Agreement (PIIA) for employees/contractors, and basic Terms of Service/Privacy Policy.
- Tier 2 (Growth/Sales): Standard Customer Agreement / Master Services Agreement (MSA) with a modular Order Form, and standard Vendor/SaaS Agreements.
- Tier 3 (Corporate/Governance): Board consent templates, stock option grant notices, and basic advisory agreements.
- Do not write everything from scratch. Leverage trusted, market-standard open-source frameworks to save time.
- Adapt frameworks like the Series Seed Documents for corporate housekeeping or standard open-source developer agreements where applicable, but tailor them to your specific risk tolerance.
- Separate commercial terms (price, term, scope) into an easily editable schedule or order form, leaving the legal boilerplate standard and un-editable by default.
- Write in plain, accessible English where possible. Overly dense legnot-only slows down sales cycles but makes internal teams bypass legal entirely.
- A template is useless if sales or HR doesn't know how to use it. Create a simple "redline playbook" indicating which clauses are non-negotiable (e.g., IP ownership, unlimited liability caps) and which have pre-approved fallback positions (e.g., standard liability multipliers, specific governing law jurisdictions).
- Set up a centralized repository (even a well-organized secure drive or early-stage CLM tool) so templates aren't sitting on individual laptops being modified dangerously out of date.
If you'd like, let me know:
I can help outline the key clauses and risk guardrails you should include.
No sources cited
A startup General Counsel should not begin by creating a giant library of every possible contract. The better approach is to build a **minimum viable legal operating system**: a small set of high-frequency templates, a clause library, negotiation rules, and approval workflows. A good template system is less about…
A startup General Counsel should not begin by creating a giant library of every possible contract. The better approach is to build a minimum viable legal operating system: a small set of high-frequency templates, a clause library, negotiation rules, and approval workflows. A good template system is less about documents and more about making repeat decisions consistently.
First, identify what the business actually signs.
Interview:
Ask:
A typical early-stage startup inventory looks like:
Many startup template collections prioritize these same categories because they recur frequently: NDAs, employment documents, IP assignments, contractor agreements, customer agreements, and website terms.
A first GC usually gets the most leverage by building templates in this order:
| Priority | Template | Why |
|---|---|---|
| 1 | Mutual NDA | Removes routine friction |
| 2 | Customer MSA | Protects revenue engine |
| 3 | Order Form | Makes sales repeatable |
| 4 | Vendor Agreement | Controls spend and risk |
| 5 | Contractor Agreement | Protects IP ownership |
| 6 | Employee Offer Letter | Enables hiring |
| 7 | CIIAA | Ensures company owns IP |
| 8 | DPA | Needed for enterprise customers |
| 9 | Advisor Agreement | Common equity/IP issue area |
| 10 | Privacy/Website Terms | Product launch foundation |
For each template, decide:
Example:
Limitation of liability
Payment terms
Indemnity
A contract playbook should capture:
This turns legal judgment into a repeatable process instead of relying on one lawyer’s memory.
Do not make every agreement a separate invention.
Create reusable clauses for:
For each clause, store:
| Field | Example |
|---|---|
| Clause name | Liability cap |
| Preferred language | Company standard |
| Acceptable alternative | Customer-friendly version |
| Never accept | Red flag version |
| Approval needed | CEO/CFO/legal only |
| Notes | Why this matters |
A common mistake is creating only Word documents.
You need three layers:
The actual agreement.
Example:
Customer MSA v1.0
Approved building blocks.
Example:
Liability clause — customer-friendly fallback
Decision rules.
Example:
"Sales may accept Net 45 payment terms. Net 60 requires CFO approval." The playbook is what allows sales, procurement, and future legal hires to operate consistently.
Create a simple matrix:
| Issue | Approval |
|---|---|
| Standard NDA | Business owner |
| Customer MSA with standard terms | Legal |
| Liability above threshold | GC |
| Security commitments | Security + Legal |
| Large discounts | Finance |
| Unlimited indemnity | Executive approval |
The goal is not to slow the company down; it is to prevent expensive exceptions.
Every template should have:
Example:
Customer MSA v1.3 Owner: Legal Approved: August 2026 Changes: Added AI data-use restriction clause A stale template repository is worse than no repository because people assume it is safe.
Pick 5–10 real transactions.
Run:
Track:
Then revise.
Even a lightweight system helps:
Required intake fields:
This prevents legal from becoming a last-minute approval desk.
The end goal is not a folder of legal documents. It is a system where the company knows what it signs, why it signs it, who can approve exceptions, and how risk decisions are made.
This prevents legal from becoming a last-minute approval desk.
The end goal is not a folder of legal documents. It is a system where the company knows what it signs, why it signs it, who can approve exceptions, and how risk decisions are made.
A good startup GC should think of the first legal-template set **less as a folder of forms and more as a lightweight legal operating system**: standard documents + approved fallback clauses + negotiation rules + approval/escalation paths. That is also how modern in-house contract-playbook guidance frames the problem.…
A good startup GC should think of the first legal-template set less as a folder of forms and more as a lightweight legal operating system: standard documents + approved fallback clauses + negotiation rules + approval/escalation paths. That is also how modern in-house contract-playbook guidance frames the problem.
Don't begin by asking, “What legal documents does a startup need?”
Ask:
That produces a much better first template set than downloading a generic “startup legal documents” checklist.
For example, a B2B SaaS company will usually prioritize customer contracts, DPAs, vendor agreements, NDAs, employment/IP documents, and corporate/equity documents. A consumer marketplace might instead put terms of service, privacy, creator/vendor agreements, and regulatory forms much higher.
I'd generally create a Tier 1 “minimum viable legal department” containing:
For standardized financing instruments, don't reinvent the wheel unnecessarily. For example, YC publishes its post-money SAFE forms and a user guide, while expressly recommending jurisdiction-specific legal review.
The IP assignment piece deserves particular attention: the company should make sure founders, employees, contractors and other contributors properly assign relevant IP to the company.
For a SaaS startup, I'd usually start with:
YC's own sales-contract materials are a useful illustration of the philosophy: start from a reasonably standardized agreement and identify the provisions most likely to vary rather than negotiating the entire contract from scratch every time.
Depending on the business:
These should be built around the company's actual product and data flows rather than copied wholesale from another startup.
The GC's job isn't necessarily to be the author of every first draft.
A smart approach is to assemble a source hierarchy:
For example, there are publicly available startup forms from organizations such as Y Combinator and other legal/startup resources. YC provides both financing documents and a standardized SaaS sales agreement, while noting that forms should be customized and legally reviewed for the company's circumstances.
The important distinction is source material versus company-approved template. The latter needs to reflect your risk tolerance, business model, jurisdictions and negotiating history.
This is where a GC adds considerably more value than simply producing forms.
For every important provision, establish:
| Issue | House position | Fallback | Escalate when |
|---|---|---|---|
| Liability cap | Preferred cap | Higher cap | Unlimited liability requested |
| Indemnity | Narrow/reciprocal | Expanded for defined risks | Broad uncapped indemnity |
| IP | Company retains its pre-existing IP; customer receives defined rights | Negotiated license | Customer demands ownership |
| Data | Company uses data only as permitted | Negotiated additional uses | Sensitive/regulatory data |
| Termination | Defined termination rights | Limited convenience termination | Immediate unilateral termination |
| Governing law | Company's preferred jurisdiction | Approved alternative | Foreign/unfamiliar jurisdiction |
The crucial concept is preferred → fallback → escalation. Current in-house guidance specifically recommends documenting primary and fallback positions and the circumstances requiring escalation.
That turns a template into a playbook.
One of the easiest mistakes is creating a 40-page contract with dozens of optional brackets.
Instead, identify three categories:
Green — business can accept without Legal
Examples:
Yellow — business can negotiate within approved parameters
Examples:
Red — GC approval required
Examples:
The goal is that Sales doesn't need to email the GC every time someone asks for net-45 instead of net-30.
Don't keep only one “perfect” clause.
For important provisions, keep:
That makes future negotiations dramatically faster.
And importantly, build the library from actual negotiated deals. Guidance on standardized contracts emphasizes that clause libraries become much more useful when grounded in the company's real negotiation history rather than being created purely theoretically.
For each template, I'd want a one- or two-page internal guide answering:
Purpose: What is this document for?
When to use: When should the business select it?
Don't use when: What situations require bespoke drafting?
Business inputs: What information must Sales/HR/Finance provide?
Negotiation priorities: Which provisions matter most?
Fallbacks: What can the business accept?
Escalations: What requires GC/CFO/CEO approval?
Common mistakes: What has gone wrong historically?
Owner: Who maintains it?
This is often more valuable than adding another 20 pages to the contract itself.
Every template should have:
Otherwise six months later Sales is circulating MSA_FINAL_v7_REALLY_FINAL.docx.
A template library should be treated as controlled legal infrastructure, not a shared-drive dumping ground.
The GC doesn't need outside counsel to review every NDA forever.
I'd spend external legal budget on validating:
Then bring routine maintenance in-house.
The goal is essentially:
Outside counsel establishes the rails → GC converts them into a repeatable system → business operates inside those rails.
I would not try to create 50 templates in month one.
A practical sequence is:
Phase 1 — Foundation
Phase 2 — Playbook
Phase 3 — Expansion
Phase 4 — Optimization
The biggest conceptual shift is this:
Don't ask, “What templates should Legal have?” Ask, “What decisions should the company never have to make from scratch again?” If a salesperson negotiates 50 MSAs and the GC has to personally decide the liability cap, indemnity, governing law, DPA language and security commitments on each one, you haven't really standardized contracting.
If the company has a house MSA, a clause library, documented fallback positions, escalation thresholds, and a simple approval workflow, you've built a legal system.
That's the real first template set.
The goal is essentially:
Outside counsel establishes the rails → GC converts them into a repeatable system → business operates inside those rails.
I would not try to create 50 templates in month one.
A practical sequence is:
Phase 1 — Foundation
Phase 2 — Playbook
Phase 3 — Expansion
Phase 4 — Optimization
The biggest conceptual shift is this:
Don't ask, “What templates should Legal have?” Ask, “What decisions should the company never have to make from scratch again?” If a salesperson negotiates 50 MSAs and the GC has to personally decide the liability cap, indemnity, governing law, DPA language and security commitments on each one, you haven't really standardized contracting.
If the company has a house MSA, a clause library, documented fallback positions, escalation thresholds, and a simple approval workflow, you've built a legal system.
That's the real first template set.
Creating the first set of standard legal templates as a startup's first General Counsel (GC) requires balancing speed, risk management, and scale. You want to unblock the business without creating unnecessary exposure or legacy…
Creating the first set of standard legal templates as a startup's first General Counsel (GC) requires balancing speed, risk management, and scale. You want to unblock the business without creating unnecessary exposure or legacy debt.
Here is a structured, step-by-step approach to building your initial template suite:
Would you like me to break down the specific priority order of templates (e.g., NDA vs. MSA vs. Employment Offer Letters) or provide a checklist for commercial contract fallback positions?
A good startup GC should think of the first legal-template project **less as “draft 20 contracts” and more as building a small legal operating system**. The core system is: **template + clause library + playbook + approval/escalation rules + version control.**
A good startup GC should think of the first legal-template project less as “draft 20 contracts” and more as building a small legal operating system.
The core system is:
template + clause library + playbook + approval/escalation rules + version control.
That approach is consistent with how modern in-house legal teams structure contract standardization.
Before drafting anything, spend a week figuring out:
Then pull the company's existing contracts—ideally the last 12–24 months—and categorize them by type, volume, revenue/risk, and how much variation they contain. High-volume, relatively standardized agreements are usually the best first candidates.
The key question is:
“What legal work happens over and over again?” That's where the first templates should come from.
For a typical early-stage B2B startup, I'd usually start with something like:
The exact list should depend heavily on the startup's business model. For example, a SaaS company should prioritize its MSA, order form, DPA, security terms and NDA; a biotech company will have a very different first set.
For financing and corporate documents, there are also established market resources rather than reinventing everything. The NVCA, for example, maintains model venture-financing documents and periodically updates them for legal and market developments.
The GC should gather:
Then identify the company's preferred positions.
For example, for a customer MSA:
| Issue | Standard | Fallback | Escalate |
|---|---|---|---|
| Liability cap | 12 months' fees | 2× fees | >2× |
| Indemnity | Mutual, limited | Expanded IP indemnity | Broad consequential liability |
| Payment | Net 30 | Net 45 | Net 60+ |
| Termination | For cause | Convenience with notice | Customer termination + refund |
| Governing law | Delaware | NY/CA | Foreign jurisdiction |
| Data | Company DPA | Customer DPA if approved | Materially broader obligations |
Those positions are more valuable than the Word document itself.
A contract playbook should capture the preferred position, acceptable fallback, escalation trigger and walk-away position for important clauses.
This is one of the biggest distinctions for a first GC.
The template answers:
What does our normal contract look like? The playbook answers:
What do we do when the counterparty asks for something different? For example:
Template: liability cap = fees paid/payable in the prior 12 months.
Playbook:
That turns the GC's judgment into institutional knowledge instead of requiring the GC to personally review every contract.
Don't just maintain entire contracts.
Create approved versions of the clauses you're likely to negotiate repeatedly:
Give each clause a simple status:
Green: standard; business team can accept.
Yellow: approved fallback; specified approval required.
Red: do not accept without GC/executive approval.
This is essentially how a clause library and playbook work together: the library provides approved language while the playbook tells the team when each version can be used.
A good template should require very little legal judgment in the ordinary case.
For example, an MSA should clearly identify:
[CUSTOMER LEGAL NAME][EFFECTIVE DATE][NOTICE ADDRESS][GOVERNING LAW][LIABILITY CAP]And distinguish those variables from language that shouldn't be edited.
I'd also put short internal drafting notes next to complicated provisions, such as:
GC NOTE — DO NOT EDIT: This is the company's standard IP ownership provision. Any change requires Legal approval. The goal is that a salesperson, finance person, HR person or operations employee can complete the safe parts without accidentally rewriting the company's risk allocation.
This is what makes the templates operational.
For example:
| Decision | Business can approve | Legal approval |
|---|---|---|
| Standard payment terms | ✓ | |
| Net 60 | ✓ | |
| Standard liability cap | ✓ | |
| Higher liability cap | ✓ | |
| Standard governing law | ✓ | |
| Customer governing law | ✓ | |
| Standard confidentiality | ✓ | |
| Broad data obligations | ✓ | |
| Uncapped liability | ✓ + executive | |
| Non-standard indemnity | ✓ |
The exact thresholds depend on the company.
This also prevents the classic startup problem where everything becomes a legal escalation, defeating the purpose of having templates in the first place.
The folder shouldn't just say:
MSA_FINAL_FINAL_v7.docxInstead, establish a canonical system:
Customer MSA Owner: Commercial Legal Version: 1.3 Effective: August 2026 Next review: February 2027
And maintain:
A template program works only if templates are consistently rolled out, reviewed periodically and updated when circumstances change.
Before declaring the templates finished, take 10–20 real historical deals and ask:
“If this had been our template, would it have worked?” Then deliberately run difficult redlines against it.
You want to discover things like:
The first template is therefore version 0.9, not the final answer.
The final product shouldn't be a giant shared drive.
I'd create something like:
Legal Hub
→ Need an NDA? → Need a customer contract? → Need a vendor contract? → Hiring someone? → Need an IP assignment? → Need corporate approval?
Each path gives the requester:
That is the point where the GC has moved from “drafting lawyer” to “legal infrastructure builder.”
I'd roughly sequence it this way:
Days 1–30 — Diagnose
Days 31–60 — Build
Days 61–90 — Operationalize
The important insight is that the first set of templates should be deliberately small. A startup gets much more value from 7 excellent, heavily used templates with clear rules than from 40 beautifully drafted documents nobody knows how to use.
And the most important deliverable isn't actually the templates. It's the institutionalization of the GC's judgment: here is our standard position, here is what we will compromise on, here is what we won't accept, and here is who gets to make the exception.
If you're thinking about this from the perspective of a first GC joining a 20–100 person startup, I can also lay out what I would put in the actual “Startup Legal Template Library v1.0” — including the specific documents, clause library, approval matrix, and folder structure.
The important insight is that the first set of templates should be deliberately small. A startup gets much more value from 7 excellent, heavily used templates with clear rules than from 40 beautifully drafted documents nobody knows how to use.
And the most important deliverable isn't actually the templates. It's the institutionalization of the GC's judgment: here is our standard position, here is what we will compromise on, here is what we won't accept, and here is who gets to make the exception.
Creating the first set of standard legal templates as a startup's first **General Counsel (GC)** requires `balancing speed, risk management, and the company's specific growth stage` . You want to enable the business to move fast without leaving the company…
Creating the first set of standard legal templates as a startup's first General Counsel (GC) requires balancing speed, risk management, and the company's specific growth stage . You want to enable the business to move fast without leaving the company exposed.
Here is a structured, step-by-step approach to building that foundational playbook:
Would you like to focus on a specific template first—such as a SaaS customer agreement , an NDA , or an employment offer letter —and look at key clauses and risk factors for that specific document?
Building the first suite of legal templates for a startup from scratch requires balancing **speed, risk management, and scalability** . As the first General Counsel (GC), you don't need a 50-page enterprise agreement on day one; you need practical, founder-friendly, and investor-ready guardrails. Here is the…
Building the first suite of legal templates for a startup from scratch requires balancing speed, risk management, and scalability . As the first General Counsel (GC), you don't need a 50-page enterprise agreement on day one; you need practical, founder-friendly, and investor-ready guardrails.
Here is the step-by-step roadmap to building your startup's foundational legal playbook:
If you'd like, tell me:
I can help you prioritize which specific template to draft first or how to structure your negotiation fallback playbook.
A good startup GC should think of the first legal templates as a **system**, not a pile of documents. The objective is to make the 80% of recurring legal work fast, while making the remaining 20% easy to spot and escalate. ### 1. Start with the business, not with a template library Before drafting, map:
A good startup GC should think of the first legal templates as a system, not a pile of documents. The objective is to make the 80% of recurring legal work fast, while making the remaining 20% easy to spot and escalate.
Before drafting, map:
Then review the last 20–50 contracts the company has actually signed. The ACC's guidance is particularly useful here: look at what the company has previously accepted, where it deviated from its template, and—most importantly—where it actually walked away.
That gives you the company's real contracting position, rather than an abstract notion of "market standard."
For a typical U.S. B2B startup, I'd prioritize roughly this way:
| Priority | Template | Why |
|---|---|---|
| 1 | Mutual NDA | Almost universally useful |
| 2 | Customer MSA | Core revenue contract |
| 3 | Order Form / SOW | Lets sales close transactions without rewriting the MSA |
| 4 | SaaS Terms / Subscription Agreement | Alternative or companion to MSA |
| 5 | DPA | Needed as soon as customer data/privacy obligations matter |
| 6 | Vendor/Procurement Agreement | Controls material suppliers |
| 7 | Contractor Agreement | IP + confidentiality + commercial terms |
| 8 | Employee Offer Letter | Standardizes hiring |
| 9 | Employee CIIA/PIIA | Protects company IP and confidential information |
| 10 | Advisor Agreement | Equity/advisory relationships |
| 11 | Website Terms | Product/website terms |
| 12 | Privacy Policy | External privacy disclosures |
Cooley GO's current startup document library, for example, includes mutual and one-way NDAs, consulting agreements, employee invention-assignment agreements, advisor agreements and website terms—roughly the same cluster I'd expect a young company to need.
The exact list changes substantially for a fintech, healthcare company, consumer app, AI company, hardware company, etc.
Create a company clause library first.
For example:
Confidentiality
Liability
IP
Data
Term/termination
A useful playbook therefore doesn't merely say "here is our preferred clause." It says preferred → fallback → redline limit → escalation trigger. That's also the structure recommended in modern contract-playbook guidance.
This is one of the highest-leverage things a GC can do.
Instead of:
Section 12 — Limitation of Liability
have the internal playbook say:
Purpose: Prevent an ordinary commercial contract from creating disproportionate company-wide exposure.
Preferred: Mutual cap at fees paid/payable in preceding 12 months.
Fallback: 2× fees.
Never accept without GC approval: Unlimited liability except narrowly defined carveouts.
Common counterparty objection: "We can't cap confidentiality/data/IP breaches."
Response: Offer a separate super-cap rather than unlimited liability.
Now sales, procurement and junior lawyers understand the reason for the position, not just the words.
This is an important architectural decision.
The template is what the counterparty sees.
The playbook is what your company sees.
For example:
Customer MSA — external
Customer MSA Playbook — internal
This separation makes the system much easier to maintain.
The end state should look something like:
Sales gets a contract request → chooses template → fills structured variables → negotiates within playbook → escalates only exceptions.
For example:
🟢 Sales can accept
🟡 Legal approval required
🔴 GC/CFO/executive approval
That is how the GC turns templates into a scalable legal operating system.
Employment is especially dangerous to make "one-size-fits-all."
For example, offer letters and invention-assignment agreements need jurisdiction-specific treatment. Cooley specifically notes that its CIIA form is intended for U.S. companies with California employees and cautions that employment restrictions need to be evaluated under applicable jurisdictional requirements.
So instead of one giant:
Employee Agreement — USA
you might maintain:
And keep the jurisdictional decision tree with them.
For an early-stage startup, I'd make an IP chain-of-title audit one of the first things the GC does.
You want to be able to answer:
"Does the company actually own everything that makes the company valuable?"
That means checking founders, employees, contractors, consultants and advisors—not just putting a good IP clause into new agreements. Startup guidance consistently emphasizes getting IP assignments into place for founders, employees and contractors.
Also identify:
This is often more valuable than spending another week polishing boilerplate.
Every template should have:
Template name
Version: v1.3
Effective date: YYYY-MM-DD
Owner: Legal
Approved by: GC
Last legal review: YYYY-MM-DD
Next review: YYYY-MM-DD
Jurisdiction: U.S./CA/etc.
Use case: Customer MSA
Status: Active / Deprecated
And maintain a short change log.
That prevents the classic startup problem where Sales has "the latest MSA," Procurement has another version, and Finance is using a six-month-old Order Form.
I would not try to build 20 perfect templates simultaneously.
Start with something like:
Then run 10–20 real transactions through them.
Every negotiation teaches you something:
Customer asks for 90-day payment terms → add fallback.
Customer objects to liability cap → add approved super-cap.
Security team asks for audit rights → create security fallback.
Sales repeatedly forgets a required field → change the intake form.
The first version should be designed to generate feedback.
The GC doesn't necessarily need outside counsel to draft every piece. The better division of labor is often:
GC
Specialist outside counsel
That approach gives the startup institutional knowledge rather than outsourcing the entire legal function.
Week 1 — Discover
Week 2 — Architect
Week 3 — Draft
Week 4 — Deploy
The key mindset is: don't ask "What legal documents does a startup need?" Ask "What recurring business decisions should Legal turn into standardized, low-friction workflows?"
That's what makes the first template set genuinely useful—and scalable as the company grows.
Building the first suite of standard legal templates for a startup requires a strategic, pragmatic approach. A General Counsel (GC) isn't just drafting documents; they are establishing the company's foundational risk profile and operational…
Building the first suite of standard legal templates for a startup requires a strategic, pragmatic approach. A General Counsel (GC) isn't just drafting documents; they are establishing the company's foundational risk profile and operational speed.
Here is how a GC typically tackles this process efficiently:
If you'd like to dive deeper, let me know:
I can help outline the key clauses and best practices for that specific document.
A startup General Counsel usually should **not start by writing a giant contract library from scratch**. The best approach is to build a small, high-leverage legal operating system: identify the company’s recurring risks, standardize the highest-volume agreements, and document when people must come back to Legal. A…
A startup General Counsel usually should not start by writing a giant contract library from scratch. The best approach is to build a small, high-leverage legal operating system: identify the company’s recurring risks, standardize the highest-volume agreements, and document when people must come back to Legal. A good template system usually includes not just documents, but also fallback positions, approval rules, and negotiation guidance.
A practical sequence:
Start by mapping where the business repeatedly touches legal issues:
Commercial
People
Corporate
Product / risk
The goal is to answer: “What agreements does the business need every week?”
A typical early-stage startup library might include:
The exact list depends heavily on whether the startup is SaaS, biotech, fintech, consumer, marketplace, etc.
Review:
Look for:
A common mistake is creating “perfect” templates that sales, recruiting, or operations cannot actually use.
Each important agreement should have three layers:
The document people actually use.
For each important clause:
| Clause | Preferred position | Acceptable fallback | Escalate when |
|---|---|---|---|
| Liability cap | 12 months fees | 2x fees | Unlimited liability |
| Indemnity | Narrow, mutual | Expanded IP indemnity | Broad business indemnity |
| Termination | 30–60 days notice | Longer notice | Immediate termination rights |
Examples:
Playbooks work because they convert legal judgment into repeatable business rules.
For every template, mark:
Green — business can accept
Yellow — negotiate within boundaries
Red — GC approval required
This prevents Legal from becoming a bottleneck.
Every template should have:
Avoid having “final_v7_REAL_FINAL.docx” living in someone’s folder.
Templates fail when people do not know:
Useful enablement:
After every meaningful deal:
The first version is usually a hypothesis. The best legal systems evolve from actual company behavior.
Days 1–30
Days 31–60
Days 61–90
The end goal is not “more legal documents.” It is a system where the company can move quickly while preserving the risks the GC cares about.