The 2% Feature Was Load-Bearing: Why MAU Is The Wrong Deprecation Signal

An essay published on dev.to under the handle dasdorf makes an unfashionable claim: you cannot decide whether to kill a feature from its usage metrics, because usage tells you who touches the front door and nothing about what is load-bearing in the basement ^[1]. It matters because the opposing belief, that low adoption is itself sufficient evidence of a small blast radius, is the assumption the author blames for six-figure incident cleanups ^[2].

The structural point is that adoption and dependency are orthogonal ^[3]. A feature can have poor end-user adoption and still be load-bearing, because the things depending on it are not end users at all: they are other systems, other teams' automations, and legacy contracts nobody re-reads ^[4]. The author reports watching teams sunset a feature at 2% monthly active users and take down three internal tools, a partner integration, and a compliance report finance runs quarterly, none of which appeared in any dashboard because none of them count as "users" in the analytics sense ^[5].

The worked example is a mid-size B2B SaaS company, anonymized by the author, who says the numbers are real ^[6]. A "Custom Export Templates" feature, built three years earlier, was touched by 1.4% of active accounts per month and cost an estimated 140 engineering hours per quarter in bug fixes, a recurring migration and on-call incidents ^[7]. On adoption-based scoring it was a top deprecation candidate, and the product team had a deck ready ^[8].

Someone ran a dependency trace before the kill-off rather than after ^[9]. The template engine turned out to feed a webhook system used indirectly by 9% of accounts, because a more popular feature, "Scheduled Reports," silently relied on the same engine for formatting ^[10]. That indirect exposure is roughly 6.4 times the direct UI share ^[11]. The billing team's invoice reconciliation script, internal and written by someone who had left two years earlier, parsed the engine's output to validate export completeness for enterprise contracts ^[12]. Two enterprise contracts worth roughly $380k ARR combined named the export format in their SOW as a deliverable capability, via the phrase "data portability," which sales had mapped to this feature during the deal ^[13].

The revised plan was not a kill. The team retired the direct-usage UI, worth about 20% of maintenance cost, and kept the template engine alive as an internal-only dependency under a smaller, clearer maintenance contract ^[14]. Net saving: about 30 hours per quarter against the 140 the deck had promised ^[15], which is roughly 21% of the projected figure and leaves about 110 hours per quarter that were never available to save ^[16].

The second-order failure is subtler. Teams that do map dependencies often map the technical graph and stop, and foreign keys, API call graphs and service dependencies miss the organizational and contractual layer almost every time, because those dependencies live in a sales engineer's Notion doc, a customer-built Zapier integration, or a CSV export scheduled into a customer's warehouse three years ago ^[17]. The author describes one team that traced every function call, API consumer and internal service, declared the feature clean, deprecated it, and was blindsided four days later by a partner's scraper hitting a public page the feature rendered ^[18]. The technical graph was accurate; it was not the whole graph ^[19].

Worth noting: this is one practitioner's account of an unnamed company, and the figures are not independently verifiable. What to watch in your own estimates is the coupling pattern rather than the anecdote: a popular feature quietly sharing an engine with an unpopular one, a revenue-recognition script with no living owner, and contract language that describes a capability rather than a product name. Each of those turns a savings number into a liability number, and none of them are visible from a spreadsheet sorted by MAU ^[20].