Native capability before custom work

The September 11 Gmail assessment exposed a maintenance problem: a custom system can still be more capable while no longer being worth building or expanding. Native search, reading, drafting and supervised organization covered much of the everyday work. The remaining value was narrower: recovery receipts, coverage versus delivery checkpoints, replay after downtime, conflict checks and enforced restrictions.

The proposed decision was to move ordinary work toward native, freeze custom expansion, and retain only safeguards the operator actually needs. The source tested one mailbox binding. It did not establish four-account routing or unattended reporting equivalence, so full retirement remained conditional. This note records the source recommendation; it does not report an executed migration or a fresh platform audit.

The paired update-watch conversation creates a feedback loop. Compare installed versions with official announcements, flag changes that alter custom-work economics, and stay quiet when unchanged. A new capability is a reason to reassess an implementation, not an instruction to delete it. A watch configuration also does not prove that its later checks ran or that alerts were delivered.

Before the next workaround, write down the exact missing capability, the least implementation needed, how the benefit will be measured, and an exit condition. Ask whether it pays back if the platform replaces it next month. Test actual tool and account coverage rather than equating a release announcement with operational equivalence.

Sources: Assess Gmail connector strategy and Set up app update automation, both September 11, 2026. Source turns, tool calls and outputs are retained in their private archives.