A company originally treated its in-house recommendation engine as a supporting subdomain — nice to have, but not why customers signed up. Two years later, customer research shows recommendation quality is now the single biggest driver of retention. What should trigger a team to revisit a subdomain's classification like this, and what does actually acting on the change typically cost the organization?

## What should trigger a second look Subdomain classification is a snapshot judgment tied to a business strategy and competitive landscape at a point in time; both of those move. Triggers to watch for include: - **quantitative evidence** — cohort or retention analysis, or driver analysis newly showing a capability moves the metrics the business cares about more than previously assumed; - **competitive signal** — a competitor visibly invests in that capability and starts winning customers on it, which both proves it can be a differentiator and creates pressure to match it; - **strategic pivot** — the company changes what it sells, turning what was an internal supporting tool into the literal product; - **commoditization running the other direction** — a capability that used to require bespoke work becomes available as a mature vendor product industry-wide, which can demote something from core to generic, worth remembering the traffic runs both ways. ## Why the review needs a gate Why deliberate, evidence-gated review matters rather than ad hoc reclassification: without a gate, classification drifts based on internal politics — whichever team's leader is most persuasive in a planning meeting claims their subdomain is 'actually core now' to justify headcount, and definitions become currency for internal budget fights rather than a genuine strategic read. Requiring outside evidence — customer research, competitive data, revenue attribution — keeps the exercise honest and defensible when it's later used to justify moving senior people or cutting investment elsewhere. ## What a promotion actually costs Cost of acting on a genuine promotion has several parts. 1. **First, a technical-debt reckoning:** a subdomain implemented under supporting-tier assumptions — fewer edge cases handled explicitly, less rigorous domain modeling, built quickly by whoever was available — usually cannot simply be relabeled; the code typically needs a deliberate investment phase, refactoring toward a richer domain model and adding the ubiquitous-language rigor and test coverage a core subdomain warrants, sometimes amounting to a partial or full rewrite. 2. **Second, staffing disruption:** promoting a subdomain to core means it now competes for the org's best engineers and closest domain-expert access, which necessarily means pulling those people away from wherever they currently are; if they're currently on a genuinely important area, this creates a real, not just perceived, trade-off elsewhere, and if poorly communicated it reads as those other teams being demoted, with real morale cost. 3. **Third, bounded-context renegotiation:** a subdomain that lived comfortably inside a shared or lightweight bounded context at supporting-tier complexity often needs to be pulled into its own dedicated context once it's core, meaning new service boundaries and migration work disentangling it from whatever it used to share space with — genuine distributed-systems work with its own risk of incidents during the transition. 4. **Fourth, organizational and reporting-line change:** teams and often org charts get redrawn around newly-core subdomains, since architecture tends to mirror communication structure, and a subdomain that now needs dedicated architecture usually also needs a dedicated, accountable team, and reorganizations carry their own well-known productivity dip during the transition. ## Moving too slowly against moving too fast Trade-off: - **moving too slowly on a genuine reclassification** means continuing to under-invest in what's now actually driving the business, ceding ground to competitors who read the signal faster; - **moving too fast on a false signal**, enthusiasm without real evidence, means paying all the above reorganization and refactor costs for a capability that isn't actually the differentiator, which is expensive theater. The evidence gate exists precisely to sit between those two failure modes. ## Streaming, worked through Worked scenario: a streaming company's shift from primarily licensing and streaming content toward personalized recommendations as an explicit differentiator over roughly a decade is a well-known industry example of a capability's strategic weight shifting over time — recommendation and personalization work went from a nice-to-have feature to being explicitly central to the value proposition, reflecting real evidence (viewing and retention data) that recommendation quality was driving the business, followed by sustained reallocation of top engineering and data-science talent and dedicated architecture built specifically around that capability rather than treating it as a bolt-on feature of the streaming platform.