All insights

Insight

The Margin-for-Moat Trade Has a Failure Mode

2026-08-22 · 4 min read

The ninth forward-deployed engineer starts Monday. The first eight are each embedded in a different customer, each maintaining a different bespoke integration, and none of them has shipped anything the other seven can reuse. Eight customers, eight snowflakes. The founder describes this to investors as a moat. The analyst working through the data room two years from now will describe it differently.

a16z’s Joe Schmidt gave this generation of AI companies its operating instruction in “Trading Margin for Moat”: software is becoming the worker rather than the worker’s tool, digital labor needs onboarding and management the way human labor always has, and the companies willing to accept services-heavy gross margins early are the ones that become the system of work. The essay is right. It is also the most selectively quoted advice in the industry, because a lot of founders heard only the first clause. Trade the margin and hire field engineers; the moat will follow.

It will not follow — not on its own. The margin-for-moat trade only pays if field work compounds into a platform, and whether it is compounding is not a matter of narrative. It is one measurable number.

Schmidt’s own evidence points at the mechanism. ServiceNow launched near 63 percent gross margin, in his telling; Workday near 54. Both climbed into the high seventies — not by firing the services people, but by letting the platform absorb the services work. The margin recovered when the software started doing what humans had been doing by hand. The part of the essay that gets quoted least is its actual instruction: automate the services motion itself.

His a16z colleague Marc Andrusko named the failure mode in “The Palantirization of Everything”: thousands of bespoke deployments nobody can maintain — a services business wearing a software valuation. His acid test is the number that settles the question. Does forward-deployed effort per mature account decline over time? If year-two accounts consume as many engineer-hours as year-one accounts, nothing is compounding. You are running a body shop with equity compensation. The valuation multiple assumes the former; the cost structure proves the latter.

What diligence eventually finds

Thomas Otter, who has spent a career inside enterprise software, adds the critique most founders would rather skip. Embedding engineers with customers is not new — he traces it to SAP’s R/1-era deployments at ICI and John Deere. The real question, in his telling, is accounting. Field engineering cost belongs in COGS, not R&D, and services revenue dressed as ARR is the sin that surfaces in diligence. His long-term warning is sharper still: a field force whose status comes from bespoke heroics will quietly resist the standardization that would make the platform real.

The honest counter to all this skepticism is that every admired platform company looked like a services firm at first. Palantir ran on forward-deployed engineers for years — by Gergely Orosz’s account it employed more of them than conventional engineers until 2016 — and Foundry emerged from that fieldwork. True. But look at what the history actually contains. Nabeel Qureshi, writing from inside it, describes product engineers watching the field solve the same problems again and again, then encoding the recurrences as platform primitives — ontology, permissioning, provenance. The compounding was staffed. It was somebody’s entire job. It did not happen as a side effect of doing good deployments. Everest Group calls Palantir a “category of one” for a reason: product engineering and embedded execution running simultaneously is rare because it is expensive and deliberate.

That is the lesson worth stealing. A platform-first field operation instruments the compounding from day one instead of reconstructing it in year three. Patterns get codified when they recur, not when someone happens to remember them. Artifacts travel across accounts instead of being rewritten inside each one. Hours per outcome are tracked per account, so Andrusko’s number is a dashboard you watch rather than a finding you dispute. And the books stay honest underneath — field cost in COGS where Otter says it belongs, so the margin line tells the truth about whether the platform is absorbing the work.

The moat was never the engineers. Engineers churn and get poached, and some leave to start the firm that competes with you. The moat is what their work compounds into — the thing that makes engagement nine start where engagement one finished.

LockedIn Labs FDE is a bet on that sentence: the compounding layer built as a product, so field work has somewhere to accrue from the first account instead of the fortieth.

LockedIn Labs FDE is the platform forward-deployed engineers carry into the enterprise — the operating reality held as a governed asset, workflows and agents as reviewable definitions, and every privileged action stopped at a named human.