ExpertsFM20Product: Inside Legora's Tech Stack: Why Token Maxing is Failing Enterprise Startups with Jacob Lauritzen, CTO @ Legora
The Twenty Minute VC (20VC): Venture Capital | Startup Funding | The Pitch · June 6, 2026
5 Selected Lessons:
reasoning_pattern · 2 framework · 1 prediction · 1 heuristic · 1
Three-phase software bottleneck diagnosis
Source
The Twenty Minute VC (20VC): Venture Capital | Startup Funding | The Pitch — 20Product: Inside Legora's Tech Stack: Why Token Maxing is Failing Enterprise Startups with Jacob Lauritzen, CTO @ Legora (June 6, 2026) · at 5:02 ▸ · at 7:45 ▸
When this applies
when a process has multiple sequential stages and a technology shift removes the constraint from one stage
The takeaway
When a historical bottleneck in a multi-stage process becomes cheap, re-identify the new bottleneck and redirect investment there rather than continuing to optimize the now-cheap stage.
Why it works
A process is only as fast as its slowest stage; once AI collapses the 'write code' stage's cost, the remaining stages (scoping/product work, and review) become the new rate limiters and deserve the next round of investment.
One level up
Continuously re-run bottleneck analysis as underlying costs shift; yesterday's constraint is not necessarily today's.
Where it stops holding
This stops working when the easy-to-identify stages aren't truly sequential/dependent, or when multiple stages are constrained simultaneously such that fixing one does nothing for overall throughput.
Detail
procedure:
- Identify the stages: product definition, build/code, review/merge.
- Note which stage used to be the rate limiter (historically: writing code).
- Recognize new cheap stage via AI tooling (code writing compressed).
- Redirect focus/org design to the newly dominant bottlenecks (product work and review).
rationale: If code is cheaper to write, the other two stages (product scoping, review) naturally become bottlenecks and the focus area should shift there.
In their words
And number two was the primary bottleneck for the past hundred years almost. So, like, the rate limiter was how quickly can you write code? That is now super cheap. So, that's sort of been compressed. And so, the bottleneck now is like the two other ends, which is review.
Review should be scoped to strategic/system impact, not line-by-line code
Source
The Twenty Minute VC (20VC): Venture Capital | Startup Funding | The Pitch — 20Product: Inside Legora's Tech Stack: Why Token Maxing is Failing Enterprise Startups with Jacob Lauritzen, CTO @ Legora (June 6, 2026) · at 7:45 ▸ · at 12:20 ▸
When this applies
when deciding what level of human oversight to apply to an increasingly automated production process
The takeaway
Reserve human review for decisions with irreversible or strategic consequences; let automation own decisions that don't change system direction.
Why it works
Humans add value by catching strategic trade-offs (architecture, security boundaries, direction), not by re-deriving mechanical correctness that AI/automated checks already verify; focusing human attention on line-level detail wastes the scarcest resource.
One level up
Allocate scarce human judgment to the parts of a process where stakes and ambiguity are highest, and automate the rest.
Where it stops holding
This stops working when current automated reviewers are not yet reliable enough to catch the mechanical issues that matter (which Jacob explicitly says is the current state — 'current review tools are not good enough').
Detail
approach: Separate mechanical/low-stakes code changes (auto-approve) from changes with systems-architecture, security, or stability implications (require human sign-off).
signals:
- change affects systems design/stability
- change affects security boundaries
- change shifts system direction strategically
rationale: No one wants to look at all the lines of code; what's important is the impact on architecture, stability, and security.
In their words
What's important is what's the impact on systems architecture? What's the impact on systems design, stability, security boundaries? How does it sort of take our system in the right direction? That's the kind of stuff that you want to review. And if that doesn't change, then maybe you don't have to review it at all.
Product defensibility lives in the wrapper, not the underlying model
Source
The Twenty Minute VC (20VC): Venture Capital | Startup Funding | The Pitch — 20Product: Inside Legora's Tech Stack: Why Token Maxing is Failing Enterprise Startups with Jacob Lauritzen, CTO @ Legora (June 6, 2026) · at 24:58 ▸
When this applies
when a product is built on top of a commoditizing core technology that multiple competitors can also access
The takeaway
When your core enabling technology is a commodity everyone can buy, build and defend value in the surrounding integration layer, not in access to the commodity itself.
Why it works
Because the underlying model is a shared, rapidly-improving commodity accessible to all competitors, durable value accrues to the domain-specific primitives, workflow integration, enterprise features, and routing logic surrounding it — remove the model and clients still choose you for those.
One level up
Durable moats sit one layer above whatever is becoming commoditized.
Where it stops holding
This stops working if the underlying model itself becomes so dominant or differentiated (e.g., one lab achieves a durable capability lead) that it alone drives purchase decisions, collapsing the value of the wrapper.
Detail
approach: Evaluate ~10 different models per task for latency/performance (rarely cost first), keep switching as the 'best model' changes bi-weekly, and invest value in legal primitives, enterprise features, and routing rather than any single model.
signals:
- clients wouldn't leave if you swapped the underlying model
- value sits in primitives/enterprise features/routing
rationale: We wouldn't exist without the models, and every time models improve our product improves, but take away a model and clients would still pick Legora — they don't buy based on the model.
In their words
Much less than most people think. The value of Lagora is there's so much more around it, whether it's like the primitives that make sense for legal, that make it more efficient to work with AI, or it's all the enterprisey features, or it's the optimal routing between models.
Co-location eliminates handover cost between roles
Source
The Twenty Minute VC (20VC): Venture Capital | Startup Funding | The Pitch — 20Product: Inside Legora's Tech Stack: Why Token Maxing is Failing Enterprise Startups with Jacob Lauritzen, CTO @ Legora (June 6, 2026) · at 38:09 ▸ · at 40:23 ▸
When this applies
when deciding between in-person/co-located vs. remote/siloed structure for a tightly interdependent small team
The takeaway
For tightly interdependent small teams solving the same problem together, minimize sequential handover by co-locating them; reserve remote work for genuinely isolated, independently-ownable problems.
Why it works
Sequential handovers between roles (doc writeup, review cycles, clarifying meetings) introduce communication overhead and misalignment that physical co-location collapses into direct, real-time collaboration.
One level up
Structure team topology around the actual dependency graph of the work, not around individual preference alone.
Where it stops holding
This stops working for engineers working on genuinely isolated problems with few dependencies, where remote work doesn't incur the same handover penalty — Jacob explicitly allows for this exception.
Detail
rule: Keep PM, designer, and engineer physically together for interdependent work; remote is acceptable for isolated problems, but that's not Legora's current need.
rationale: If you have a PM and a designer and an engineer and they just sit together, you can almost not even have the handover; if siloed, you lose so much efficiency to Zoom calls, unclear docs, and extra review rounds.
In their words
If you have a PM and a designer and an engineer and they just sit together, you can almost not even have the handover. You can just be like, run at this problem and do it the three of you, then it's done.
Engineer role shifts from code-writing to systems design and meta-engineering of agents
Source
The Twenty Minute VC (20VC): Venture Capital | Startup Funding | The Pitch — 20Product: Inside Legora's Tech Stack: Why Token Maxing is Failing Enterprise Startups with Jacob Lauritzen, CTO @ Legora (June 6, 2026) · at 7:45 ▸ · at 10:18 ▸
When this applies
when a core execution skill in your industry becomes automatable
The takeaway
When a task is automated, the remaining human value migrates to designing and constraining the system the automation operates within.
Why it works
As the lower-level task (writing lines of code) is automated, the valuable human skill moves up an abstraction layer to designing the system and the guardrails within which automated agents operate.
One level up
Track where automation is eating a skill and proactively relocate your people one abstraction layer above it.
Where it stops holding
This stops working in domains where there is no meaningful higher abstraction layer to move to, or where systems design itself becomes automatable too.
Detail
approach: Build a 'developer experience for agents' function: write guardrails/rules that constrain what agents can/can't do, gather good data, and let agents self-improve within those bounds.
signals:
- code base and agent usage both growing
- need for mechanistic enforcement of system behavior
- need for custom rules agents must obey
rationale: The job of an engineer is changing from typing code to thinking about what the system looks like and what bets to make.
In their words
The job of an engineer is changing from typing a bunch of code to sort of one layer above it, which is what does the system look like?