When a team can't agree whether a piece of functionality is a supporting subdomain or a generic one, what concrete test should they apply, and why does getting this specific distinction right matter more than it might seem?

## The two-question test The two-question test works by filtering each candidate subdomain through **genericity** and **competitive relevance**. - **Genericity asks:** would a solution built by a specialist vendor for hundreds of other companies work here basically unchanged, module for module? - **Competitive relevance asks:** if we make this exceptional, does it change why customers pick us over competitors, or move a metric investors care about (retention, conversion, margin)? | Relevance | Genericity | Verdict | |---|---|---| | Yes | regardless of the genericity answer | means **core** | | No | No — it needs business-specific logic no vendor product captures | means **supporting** | | No | Yes | means **generic** | ## The test applied Concretely: - **Address validation for shipping is generic** — commodity APIs solve this identically for everyone. - **A carrier-rate calculator** encoding this company's negotiated contracts with specific carriers, its own fuel-surcharge rules, and its own multi-carrier fallback logic **is supporting** — no vendor product ships with your specific contracts baked in, but calculating shipping cost correctly, while necessary, isn't why a customer picks this retailer over another. - **Route optimization** that meaningfully cuts delivery time and is the actual reason customers choose this company **might be core**. ## The stakes Why this matters more than it looks: architecture and staffing decisions cascade from this categorization. - **Supporting subdomains mis-classified as generic** often get 'solved' by buying a rigid SaaS package that assumes a generic workflow; when the business's specific rules don't fit the vendor's data model, the team ends up building brittle workarounds on top of a black-box product — often worse than a small, clean in-house service would have been. - **Conversely, mis-classifying supporting as core** inflates cost: teams over-model, add unnecessary abstraction layers, and assign senior architects to something that will never be a differentiator, slowing delivery on capabilities that just need to be correct and low-maintenance. ## What each direction costs Trade-offs: getting genericity right saves buy-vs-build money and reduces surface area (fewer systems to maintain, vendor handles patches and compliance). - **But buying always costs some flexibility** — you inherit the vendor's model of the problem, and if your business rules diverge from that model (common for supporting subdomains) you pay an integration/workaround tax. - **Building supporting subdomains yourself buys flexibility** but costs ongoing maintenance — you own every bug. ## Failure modes - **A frequent one is vendor-lock pain** — a team buys a generic-looking SaaS product for what's actually a supporting subdomain (a pricing engine that can't represent the company's tiered B2B contract discounts), then spends more engineering hours on configuration workarounds and support tickets than a focused in-house rules engine would have cost. - **Another is accidental complexity creep** — because nobody explicitly labeled something 'supporting, not core,' the team defaults to gold-plating it with elaborate architecture and extensive test matrices, burning velocity on a part of the system that just needs to be correct, not extensible or elegant. ## Billing, worked through Worked scenario: a B2B analytics SaaS company's billing must apply usage-based tiers, enterprise custom contracts, proration, and multi-currency invoicing — business-specific enough that a generic billing platform's default plan model doesn't fully capture it. Teams sometimes default to 'billing = generic, use the vendor out of the box' and then discover mid-project that enterprise contract terms don't map to the vendor's primitives, forcing a rebuild. The correct classification is supporting: use generic payment RAILS for moving money, but build a thin in-house billing/contract layer on top that encodes the company-specific rules, rather than forcing a generic billing product to do something it wasn't designed for. Recognizing that 'payment processing' and 'contract-specific billing logic' are two different subdomains — one generic, one supporting — avoids both failure modes at once. ## When to run the test again Teams should re-run this test periodically: - **whenever a supporting subdomain's business rules stabilize** into a widely adopted industry pattern, it may be turning generic and become buyable; - **whenever a generic capability starts requiring deep business-specific customization** no vendor supports well, it may need to be pulled in-house as supporting.