How Forward Deployed Engineering is done at Decagon — Sunny Rekhi
Decagon splits deployment between configuring each customer’s agent and turning repeated enterprise requests into product features. The scarce skill is resisting brittle one-offs.
Decagon describes two deployed functions: configure the customer’s agent and turn field requests into reusable product work. After roughly **25 custom integrations**, it built a self-serve path; the company also grew from **50 to 500 people** in a year.
Builders should record the desired outcome before implementation, prove value on a narrow workflow, and inspect every custom request for reuse. If engineers repeatedly configure the same behavior, move that capability into natural-language or self-serve product controls.
Decagon describes two deployed functions: configure the customer’s agent and turn field requests into reusable product work. After roughly **25 custom integrations**, it built a self-serve path; the company also grew from **50 to 500 people** in a year. Builders should record the desired outcome before implementation, prove value on a narrow workflow, and inspect every custom request for reuse. If engineers repeatedly configure the same behavior, move that capability into natural-language or self-serve product controls. The approach depends on distinguishing repeatable needs from genuinely customer-specific ones. Productizing too early can overgeneralize a single account’s constraints, while moving fast with patches can leave customers owning a brittle black box.
This makes repeated customer configuration a concrete product signal: prove a narrow outcome, detect recurring requests, then replace bespoke engineering with reusable controls. It confirms forward deployment as a route to product leverage while defining its central judgment call—when evidence is sufficient to generalize—because premature productization and prolonged patching create different forms of brittleness.