# Primitive-First Design Absorbs Conflicting Feedback Without Scope Creep ## Claim When user feedback conflicts, building composable primitives instead of point features lets users resolve the conflict themselves by combining primitives their own way, instead of forcing the product to pick a winner. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds for tools with a genuine underlying compositional model — graphs, pipes, blocks, node systems — where two users' contradictory requests can both be satisfied by different arrangements of the same small primitive set. - Breaks down for products where the conflicting requests are about core information architecture or business logic that can't be decomposed into neutral primitives — someone still has to decide, e.g., what a checkout flow's steps are. - Doesn't mean ignoring feedback; it means changing what layer the response happens at (a new primitive or connection type, not a new fixed feature). ## Evidence Caidan Williams describes deliberately not building an "everything app" for Terminal Graph, instead building primitives (nodes, pipe-style data connections) that let users compose what they individually need, specifically as a response to beta feedback that pulled in different directions. > [!quote] > "I'm trying to make sure I'm not building like an everything app... The way that I'm trying to focus on building this is I want to build the primitives such that other people can build out what they need with it." ## Links - [[Visual Thinking MOC]] — composable primitives as the answer when users want incompatible things - [[3. Resources/Permanent Notes/Core Abilities Must Be Consumer-Neutral Primitives Not One Interface's Mirror]] — because contrasts on angle; that note is about a shared API primitive staying neutral across callers (REST, CLI, agent), this one is about a product surface staying neutral across conflicting user requests — same "don't let one demand shape the primitive" discipline, different layer - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — because applies-in; a reusable founder heuristic for handling contradictory beta feedback without feature sprawl - [[3. Resources/Permanent Notes/Instincts Are Reliable Ideas Are Not So Test Small Bets on Proven Foundations]] — because extends; primitive-first design is itself a testable instinct, not a guaranteed-correct rule - [[3. Resources/Permanent Notes/A Release Lead's Output Is Mostly Subtraction]] — because contrasts: the design-side way to avoid the cut entirely, by shipping a primitive rather than adjudicating between the requests. ## Tests / falsifiers - If two beta users' contradictory feature requests turn out to require genuinely different underlying data models (not just different arrangements of existing primitives), the primitive-first response fails and a real product decision is unavoidable. - Track whether Terminal Graph's blueprint-sharing mechanism (packaging primitive combinations as reusable workflows) actually reduces onboarding friction versus documentation-based teaching — that's the source's own stated next test. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Podcasts/Building Terminal Graph, a Spatial Development Environment, with Caidan Williams]] — Williams's full account of building Terminal Graph solo, the primitive-vs-everything-app tension, and the blueprints roadmap.