Pattern
Tool Complementarity
Tools should not compete for the same ontological space. Each has a domain. Clear boundaries. Handoff protocols, not redundancy.
"Equipment is essentially 'something in-order-to...' A totality of equipment is constituted by various ways of the 'in-order-to.'"
— Heidegger, Being and Time
Definition
Tool Complementarity means each tool has a distinct purpose that doesn't overlap with others. The hammer is for hammering; the saw is for sawing. You don't debate which to use—the task determines the tool.
In Heidegger's analysis, tools form a "totality of equipment"—an interconnected system where each tool points to others. The hammer refers to the nail, the nail to the wood, the wood to the house. Tools don't compete; they complement.
Software tools should follow this principle. If two tools can accomplish the same task, confusion arises. The user must stop and think: "Which do I use?" This breaks flow. Clear domains eliminate the question.
"When tools have clear domains, the question 'which tool?' never arises."
Principles
Non-Overlapping Domains
Each tool owns a clear territory. When domains threaten to overlap, redraw boundaries or eliminate redundancy.
✓ Claude Code for creation, WezTerm for execution
✓ Notion for documents, GitHub for code
✓ One tool per job, not "also works for..."
Handoff Protocols
Where tools meet, define explicit handoffs. The output of one becomes the input of another. Clear interfaces, not blurred responsibilities.
✓ "Claude writes, user deploys"
✓ API contracts between services
✓ Documented transition points
Totality of Equipment
Tools should reference each other, forming a coherent system. The design tool points to the development tool, which points to the deployment tool. A complete chain.
✓ Tools that integrate, not isolate
✓ Shared data formats and protocols
✓ Workflow that flows through tools naturally
Eliminate Redundancy
Two tools for the same purpose creates confusion and maintenance burden. Choose one. Commit. Eliminate the other.
✓ Regular audit of tool overlap
✓ Deprecation paths for redundant tools
✓ Single source of truth for each function
When to Apply
Apply When
- • Users ask "which tool should I use?"
- • Multiple tools solve the same problem
- • Workflow friction at tool boundaries
- • Maintenance burden is duplicated
- • Onboarding involves tool choice paralysis
Consider When
- • Overlap provides resilience
- • Different contexts need different tools
- • Migration is in progress
- • User expertise varies widely
Reference: CREATE SOMETHING Domains
The Four Properties
Each property has a clear domain. Philosophy goes to .ltd. Research goes to .io. Experiments go to .space. Client work goes to .agency. The question "where does this belong?" always has one answer.
Part of the CREATE SOMETHING Pattern Library