Why Forward Deployed Engineering Beats Consulting

The traditional consulting model sells slides. The forward-deployed model sells outcomes backed by code that the client can keep running after you leave.

The unit economics

Three things make the FDE model work where vanilla consulting fails:

• Margin on retained tooling. The CLI you build for client A becomes the foundation for client B. You amortize R&D across the book.
• Insider's view of the integration boundary. Most enterprise AI failures live at the seam between the model and the system of record. FDEs sit on that seam.
• Compound learning. Every engagement generates internal patterns. If you discipline yourself to write them down, your second year is 5–10× more efficient than your first.

Why Palantir saw it first

Palantir built FDE in the early 2010s because the CIA wouldn't accept slides — they needed working software inside SCIFs. The pattern that emerged was: small teams of engineers parachute into the customer environment, ship working integrations in weeks, then transition to a customer team while staying involved.

The shape that pattern produces is durable revenue at consulting-like dollar values with software-like retention.

What I'm actually doing at Benmore

I'm building the Foundry CLI to make FDE engagements repeatable. Each engagement contributes patterns, integrations, and skills back to the CLI; the next engagement starts further ahead than the last. That's the entire game.

The win condition is not "deliver the project." It's "deliver the project AND compound the toolkit."