Generic Solution vs Case-Specific Solution
Usually an abstraction-timing decision.
- Really about
- Whether reuse is real yet or merely hoped for.
- Not actually about
- Whether genericity sounds smarter than practicality.
- Why it feels hard
- Generic work feels strategic; case-specific work feels humble but often truer.
The decision
Should we build for broad reuse now or solve this specific case directly?
Usually an abstraction-timing decision.
Default stance
Where to start before any evidence arrives.
Solve the specific case first unless repeated demand is already proven.
Options on the table
Two poles of the trade-off
Neither is the right answer by default. Each option's conditions, strengths, costs, hidden costs, and failure modes when misused are laid out in parallel so you can read across facets.
Option A
Generic Solution
Best when
Conditions where this option is a natural fit.
- multiple real consumers already exist
- variation is known and recurring
- shared constraints are understood
Real-world fits
Concrete environments where this option has worked.
- internal frameworks with several real teams depending on them
- repeated workflow tooling with known, stable variance
- common infrastructure components with proven shared demand
Strengths
What this option does well on its own terms.
- reuse
- consistency
- potential leverage
Costs
What you accept up front to get those strengths.
- upfront complexity
- more design effort
- slower immediate delivery
Hidden costs
Costs that surface later than expected — the main thing novices miss.
- genericity can outrun actual demand
- edge cases can dominate design too early
Failure modes when misused
How this option breaks when applied to the wrong context.
- Creates abstraction addiction and platform-before-product dynamics.
Option B
Case-Specific Solution
Best when
Conditions where this option is a natural fit.
- need is local and immediate
- variation is not yet understood
- speed matters more than speculative reuse
Real-world fits
Concrete environments where this option has worked.
- single-team product features
- first implementations of a new workflow
- bounded internal tools solving one near-term pain
Strengths
What this option does well on its own terms.
- clarity
- speed
- better grounding in actual need
Costs
What you accept up front to get those strengths.
- duplication may rise
- future consolidation may be needed
Hidden costs
Costs that surface later than expected — the main thing novices miss.
- shortcuts can harden into defaults
Failure modes when misused
How this option breaks when applied to the wrong context.
- Creates scattered local fixes that later resist generalization.
Cost, time, and reversibility
Who pays, how it ages, and what undoing it costs
Trade-offs are rarely zero-sum and rarely static. Someone pays, the payoff curve shifts with the horizon, and the decision has an undo cost.
Option A · Generic Solution
Who absorbs the cost
- Current implementation team
- Future consumers if complexity leaks outward
Option B · Case-Specific Solution
Who absorbs the cost
- Future consolidation team
- Adjacent teams if duplication spreads
Option A · Generic Solution
Wins when reuse is already real enough to justify upfront complexity.
Option B · Case-Specific Solution
Wins early by preserving clarity and letting the real pattern emerge.
What undoing costs
Moderate
What should force a re-look
Trigger conditions that mean the answer may have changed.
- A second and third real consumer emerge
- Variation patterns stabilize
How to decide
The work you still have to do
The reference can frame the trade-off; only you can weight the factors against your context.
Questions to ask
Open these in the room. Answering them is most of the decision.
- Who else needs this today, not hypothetically?
- What variation do we actually understand?
- If we make this generic now, who will pay the complexity cost?
- What would we lose by solving the specific case first?
Key factors
The variables that actually move the answer.
- Number of consumers
- Known variation
- Delivery pressure
- Reuse evidence
Evidence needed
What to gather before committing. Not after.
- Consumer count
- Variation inventory
- Duplicate implementation examples
- Adoption demand
Signals from the ground
What's usually pushing the call, and what should
On the left, pressures to recognize and discount. On the right, signals that genuinely point toward one option or the other.
What's usually pushing the call
Pressures to recognize and discount.
Common bad reasons
Reasoning that feels convincing in the moment but doesn't hold up.
- We might need flexibility later
- Duplication is always bad
Anti-patterns
Shapes of reasoning to recognize and set aside.
- Building a framework before the second real consumer exists
- Rebuilding similar things repeatedly while pretending no pattern exists
What should push the call
Concrete signals that genuinely point to one pole.
For · Generic Solution
Observations that genuinely point to Option A.
- Multiple actual consumers
- Repeated pattern confirmed
For · Case-Specific Solution
Observations that genuinely point to Option B.
- Single current use
- Unclear future shape
AI impact
How AI bends this decision
Where AI accelerates the call, where it introduces new distortions, and anything else worth knowing.
AI can help with
Where AI genuinely reduces the cost of making the call.
- AI can compare multiple implementations to discover whether a true pattern exists.
AI can make worse
Distortions AI introduces that didn't exist before.
- AI makes generic scaffolding cheap, increasing the temptation to generalize too early.
Relationships
Connected decisions
Nearby decisions this is sometimes confused with, adjacent decisions that are often entangled with this one, related failure modes, red flags, and playbooks to reach for.
Easy to confuse with
Nearby decisions and how this one differs.
-
That decision is about org-level investment. This one is about the shape of a specific solution.
-
That decision is about optionality inside a solution. This one is about whether the solution covers multiple cases at all.
- Adjacent concept A code-review-time abstraction decision
Extracting a helper is a local refactor. This decision is a lifecycle commitment to serve more than one concrete case.