A team is deciding whether to buy a vendor solution or build in-house for a given piece of functionality. How should classifying that functionality as core, supporting, or generic drive the buy-vs-build decision, and what goes wrong when a team gets the mapping backwards?

## The default matrix The default matrix is: | Subdomain | Default stance | |---|---| | **core** | build with top talent and deep modeling | | **supporting** | build lean and pragmatic, often with less senior staffing | | **generic** | buy, license, or adopt open source and wrap with a thin adapter | This isn't an absolute law — vendor maturity, cost, and compliance needs can shift it — but it's the correct starting default, and deviations should be justified explicitly rather than drifting in ad hoc. ## Why the default exists Why this exists: engineering capacity is finite and slow to grow (hiring and onboarding take months), so every hour spent hand-rolling a solved problem is an hour not spent on what actually grows revenue or retention. Buying generic capability also offloads ongoing burden onto a vendor whose whole business is doing that well: - security patching; - uptime SLAs; - compliance certifications. A startup building custom session management is implicitly taking on the liability of getting session-fixation, CSRF, and token-rotation bugs right, which specialized vendors have already hardened through years of attack exposure. ## What each side trades away Trade-offs: - **Buying trades control and flexibility for speed and safety** — you inherit the vendor's data model, pricing, and roadmap, and if the vendor changes pricing or sunsets a feature you're exposed to vendor risk. - **Building trades speed and safety for control** — you own every bug, every compliance audit, every scaling problem, but can shape the tool exactly to your model. For core subdomains this trade clearly favors building despite the cost, because renting your competitive edge undermines the whole point of differentiation — if a competitor can license the same capability you use, your product converges toward theirs. ## Getting the mapping backwards Failure modes run in both directions. 1. **Buying core:** a fintech startup whose differentiator is risk-scoring logic outsources that scoring to a third-party API to move fast. This looks efficient initially, but the startup then can't differentiate on decision quality (competitors using the same vendor API get similar scores), can't quickly iterate on scoring tied to its own risk appetite, and eventually needs a costly in-house rebuild once stakeholders press for explainability the vendor's black box can't provide. The production symptom: feature requests around the core differentiator take disproportionately long because they route through a vendor's roadmap and support process instead of an internal team that can ship the same week. 2. **Building generic:** an e-commerce company hand-builds its own password-reset and session system instead of adopting a mature identity provider, reasoning 'auth is critical, we want full control.' The symptom in production is a security incident — weak password-reset token entropy, missing login rate limiting — that a mature identity vendor would already have hardened against, while the senior engineers who built and maintain the system are unavailable for the product's actual differentiating features. ## The softer version of the same mistake A softer, more common failure is mis-scoping a supporting subdomain as generic and adopting a rigid vendor tool, then discovering business-specific rules don't fit — spending more engineering time on vendor workarounds than a lean custom build would have cost. This is the 'wrong-shaped buy': buying is right in spirit but the specific vendor product's assumptions don't match the business's actual, supporting-not-generic, rules. ## Ride-hailing, worked through Worked scenario: a ride-hailing company's core is real-time driver-rider matching and dynamic pricing — built and continuously refined in-house because it's the entire competitive edge. Its payment processing is generic — handled via commodity payment rails rather than building card-network integrations from scratch, despite payments being central to completing a ride, because payment processing itself isn't why riders choose one app over another. This illustrates that 'important to the business' and 'core subdomain' aren't synonyms — importance alone doesn't justify building; competitive differentiation does.