Build vs. Buy at Headcount Zero
Running a portfolio without headcount changes how you answer build-versus-adopt. The reasoning generalizes past any one tool.
2057 Holdings — operating note
A portfolio run without headcount makes the build-versus-adopt question differently than a funded team does. Recently that question was LangChain. The reasoning generalizes past this one tool.
The default assumption is wrong in both directions
The reflex for a solo operator is adopt everything — fewer things to maintain, less code to own. The opposite reflex, in engineering-led shops, is build everything.
Both skip the actual test: does this remove work I understand, or hide work I need to see?
Where adopting wins
Anything that is not differentiating and is genuinely someone else's core competence. Payments. Identity. Email deliverability. Edge compute. I do not run my own anything in those categories and never will.
Observability belongs on that list, and it exposed a real gap. There is no systematic tracing across the model calls in this estate — no answer to how often does a model fall through to fallback, or what is p95 on the verification step. That is a deficiency, and the answer is a managed gateway, not a rewrite.
Where adopting loses
The verification architecture is the differentiator. Findings are accepted only when one lab composes and two independent labs agree — and a lab that fails to answer cannot supply consent. That property is the product. Routing it through a general-purpose abstraction would mean writing it as custom code inside someone else's framework: paying the abstraction cost without collecting the benefit.
It also nearly cost a real defect. A composing model was silently returning empty and falling through to a fallback — a three-lab pipeline running as two, with no error, normal latency, and plausible output. It was caught because the call path was owned and instrumented. Behind a vendor abstraction it presents as a generic provider hiccup.
The three costs worth pricing honestly
Maintenance surface. Custom code is surface only one person understands. Real, and it does not go away.
Legibility. In diligence, "standard stack" reads more legibly than "bespoke." Also real.
Dependency risk. The mirror image. A framework is an upstream dependency with its own release cadence, breaking changes, and transitive tree. At headcount zero, a breaking change in a framework you did not write costs more than a bug in code you did.
The first two are the case for adopting. The third is why they do not automatically win.
The test, stated plainly
Adopt where the work is undifferentiated and the vendor is better at it than you will ever be.
Refuse where the work is the differentiation, or where the abstraction would blind you to the failure modes that matter most.
The mistake is not choosing one side. It is applying one answer everywhere, and then discovering which parts of the system you can no longer see into.
The silent demotion, in twenty seconds.
This piece first appeared on jessemyers.ai.