Why Frontend Teams Should Stop Building React Components Without Clear Purpose

A developer discussion about introducing a new Heading component sparked a broader debate on how teams make architectural decisions in shared codebases. The core issue was that the proposed component duplicated functionality already handled by native HTML elements and an existing Text component, with the only justification being personal preference. Every new abstraction carries long-term costs including documentation, testing, maintenance, and team confusion, which require solid engineering rationale. The author argues that abstractions should add real behavior — such as design token mapping or responsive typography — not merely repackage existing syntax. A simple guiding principle emerged from the discussion: abstract behavior, not syntax, and enforce one concept per API to reduce ambiguity and overlapping responsibilities.