dont-reinvent-the-wheellisted

# Don't Reinvent the Wheel Decide whether one specific software capability should be reused, integrated, bought, adapted, or built from scratch. Keep custom implementation as a real option; reuse is valuable only when total cost and risk are lower. Do not interrupt ordinary implementation for small utilities, domain-specific business logic, or choices the user has already settled. Use judgment based on likely effort, maintenance burden, risk, differentiation, and reversibility. ## Workflow ### 1. Identify the capability Establish: - the specific capability being evaluated; - must-have behavior and non-negotiable constraints; - the relevant stack, deployment context, and data boundary; - whether the capability is product differentiation or table stakes. Use explicit assumptions for small uncertainties. If unresolved requirements would materially change the candidate set or decision, use or recommend `grilling`; do not reproduce an interview workflow here. ### 2. Inspect the repository first When repository context is available, inspect manifests, lockfiles, current dependencies, framework and platform configuration, infrastructure and deployment configuration, existing abstractions, and code that may already provide the capability. Never recommend adding what the project already has. ### 3. Consider the option ladder Evaluate in this default order: 1. existing project capability; 2. native language, framework, SDK, database, cloud, or platform capability; 3. curren