decision-frameworksStructured decision-making patterns for common engineering choices โ library selection, architecture, build vs buy, prioritization, reversibility analysis, and ADRs. Use when choosing between tools, architectures, or approaches, or when documenting technical decisions.
Install via ClawdBot CLI:
clawdbot install wpank/decision-frameworksStructured approaches for making engineering decisions with confidence and traceability.
npx clawhub@latest install decision-frameworksUse a weighted scoring matrix when comparing 3+ options across measurable criteria.
| Criteria | Weight | Option A | Option B | Option C |
|----------------------|--------|----------|----------|----------|
| Performance | 5 | 4 (20) | 3 (15) | 5 (25) |
| Developer Experience | 4 | 5 (20) | 4 (16) | 3 (12) |
| Community Support | 3 | 5 (15) | 3 (9) | 2 (6) |
| Learning Curve | 3 | 3 (9) | 4 (12) | 2 (6) |
| Cost | 2 | 5 (10) | 3 (6) | 4 (8) |
| Total | | 74 | 58 | 57 |
How to use:
Follow this decision tree:
Is it a core differentiator for your product?
โโโ YES โ Build it (own the competitive advantage)
โโโ NO
โโโ Does a mature, well-maintained solution exist?
โ โโโ YES โ Buy / adopt it
โ โโโ NO โ Build, but keep it minimal
โโโ Is the integration cost higher than building?
โโโ YES โ Build
โโโ NO โ Buy / adoptFactor comparison:
| Factor | Build | Buy / Adopt |
|----------------------|--------------------------------|---------------------------------|
| Maintenance cost | Ongoing โ your team owns it | Vendor/community maintains it |
| Customization | Unlimited flexibility | Limited to extension points |
| Time to market | Slower โ development required | Faster โ ready-made |
| Team expertise | Must have or acquire skills | Abstracted away |
| Long-term cost | Scales with internal capacity | License/subscription fees |
| Vendor lock-in risk | None | Medium to high |
| Security control | Full audit capability | Dependent on vendor transparency |
Evaluate candidate libraries against these criteria before adopting:
| Criterion | What to Check | Red Flag |
|--------------------------|----------------------------------------------------|------------------------------------|
| Maintenance activity | Commits in last 90 days, open issues trend | No commits in 6+ months |
| Community size | GitHub stars, npm weekly downloads, Discord/forum | < 1k weekly downloads for critical lib |
| Bundle size | Bundlephobia, tree-shaking support | > 50 KB gzipped for a utility lib |
| TypeScript support | Built-in types vs DefinitelyTyped, type quality | No types or outdated @types |
| Breaking change history | Changelog, semver adherence, migration guides | Frequent majors without guides |
| License | OSI-approved, compatible with your project | AGPL in a SaaS product, no license |
| Security audit | Snyk/Socket score, CVE history, dependency depth | Known unpatched CVEs |
| Documentation quality | Getting started guide, API reference, examples | README-only, no examples |
Quick heuristic: If you cannot replace the library within one sprint, treat the decision as a one-way door (see Reversibility Check below).
Use these tradeoff tables when choosing between architectural approaches.
| Factor | Monolith | Microservices |
|---------------------|----------------------------------|--------------------------------------|
| Complexity | Low at start, grows over time | High from day one |
| Deployment | Single artifact | Independent per service |
| Team scaling | Harder beyond 10-15 engineers | Enables autonomous teams |
| Data consistency | ACID transactions | Eventual consistency, sagas |
| Debugging | Single process, easy tracing | Distributed tracing required |
| Best when | Early-stage, small team, MVP | Proven domain boundaries, scale needs |
| Factor | SQL (Relational) | NoSQL (Document/Key-Value) |
|---------------------|----------------------------------|--------------------------------------|
| Schema | Strict, enforced | Flexible, schema-on-read |
| Relationships | Native joins, foreign keys | Denormalized, application-level joins |
| Scaling | Vertical (read replicas help) | Horizontal by design |
| Consistency | Strong (ACID) | Tunable (eventual to strong) |
| Query flexibility | Ad-hoc queries, aggregations | Limited to access patterns |
| Best when | Complex relations, reporting | High write volume, flexible schema |
| Factor | REST | GraphQL |
|---------------------|----------------------------------|--------------------------------------|
| Simplicity | Simple, well-understood | Schema definition required |
| Over/under-fetching | Common โ multiple endpoints | Clients request exact fields |
| Caching | HTTP caching built-in | Requires custom caching layer |
| Tooling | Mature ecosystem | Growing โ Apollo, Relay, urql |
| Versioning | URL or header versioning | Schema evolution, deprecation |
| Best when | CRUD APIs, public APIs | Complex UIs, mobile + web clients |
| Factor | SSR | CSR | SSG |
|---------------------|------------------------|------------------------|-----------------------------|
| Initial load | Fast (HTML from server) | Slow (JS bundle parse) | Fastest (pre-built HTML) |
| SEO | Excellent | Poor without hydration | Excellent |
| Best when | Personalized pages | Dashboards, SPAs | Blogs, docs, marketing |
| Factor | Monorepo | Polyrepo |
|---------------------|----------------------------------|--------------------------------------|
| Code sharing | Trivial โ same repo | Requires published packages |
| CI/CD complexity | Needs smart filtering (Turborepo) | Simple per-repo pipelines |
| Best when | Shared libs, aligned releases | Independent teams, different stacks |
Score and rank features/tasks:
RICE Score = (Reach x Impact x Confidence) / Effort| Factor | Scale |
|------------|--------------------------------------------------------|
| Reach | Number of users/events affected per quarter |
| Impact | 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal |
| Confidence | 100% = high, 80% = medium, 50% = low |
| Effort | Person-weeks (or person-sprints) |
| Category | Meaning | Budget Target |
|--------------|------------------------------------------------|----------------|
| Must | Non-negotiable for this release | ~60% of effort |
| Should | Important but not critical | ~20% of effort |
| Could | Desirable if time permits | ~15% of effort |
| Won't | Explicitly out of scope (this time) | ~5% (planning) |
Classify every significant decision as a one-way or two-way door.
| Aspect | One-Way Door (Type 1) | Two-Way Door (Type 2) |
|------------------|-------------------------------------|-------------------------------------|
| Definition | Irreversible or very costly to undo | Easily reversed with low cost |
| Examples | Database engine migration, public API contract, language rewrite | UI framework for internal tool, feature flag experiment, library swap behind interface |
| How to identify | Would reverting require > 1 sprint of rework? Data migration? Customer communication? | Can you revert with a config change, flag toggle, or single PR? |
| Approach | Invest in analysis, prototype, get stakeholder sign-off | Decide fast, ship, measure, iterate |
| Time to decide | Days to weeks โ thorough evaluation | Hours โ bias toward action |
Rule of thumb: Wrap risky choices behind interfaces/abstractions. This converts many one-way doors into two-way doors by isolating the implementation from consumers.
Document significant decisions using a lightweight Architecture Decision Record.
# ADR-NNNN: [Short Title]
## Status
[Proposed | Accepted | Deprecated | Superseded by ADR-XXXX]
## Context
What is the problem or situation that motivates this decision?
Include constraints, requirements, and forces at play.
## Decision
What is the change being proposed or adopted?
State the decision clearly and concisely.
## Consequences
### Positive
- [Benefit 1]
- [Benefit 2]
### Negative
- [Tradeoff 1]
- [Tradeoff 2]
### Risks
- [Risk and mitigation]Store in docs/adr/ or decisions/. Number sequentially. Never delete โ mark superseded. Review during onboarding and quarterly audits.
| Anti-Pattern | Description | Counter |
|--------------------------|------------------------------------------------------|---------------------------------------------|
| Analysis Paralysis | Endless evaluation, no decision made | Set a decision deadline; use the matrix |
| HiPPO | Highest Paid Person's Opinion overrides data | Require data or a scored matrix for all options |
| Sunk Cost Fallacy | Continuing because of past investment, not future value | Evaluate options as if starting fresh today |
| Bandwagon Effect | Choosing because "everyone uses it" | Score against your actual criteria |
| Premature Optimization | Optimizing before measuring or validating need | Profile first; optimize only proven bottlenecks |
| Resume-Driven Development | Picking tech to pad a resume, not to solve the problem | Align choices with team skills and project goals |
| Not Invented Here | Rejecting external solutions out of pride | Run the Build vs Buy framework honestly |
Generated Mar 1, 2026
A startup building a financial dashboard needs to choose a charting library. They evaluate options like Chart.js, D3.js, and Highcharts based on criteria such as performance, bundle size, and licensing to ensure compliance and fast load times. This decision impacts user experience and development speed.
An e-commerce company must decide whether to build a custom payment gateway or integrate with a third-party service like Stripe. They analyze factors like core differentiation, maintenance costs, and integration complexity to optimize for security and scalability while controlling expenses.
A healthcare software provider is designing a patient management system and needs to choose between a monolith or microservices architecture. They weigh factors like data consistency, team autonomy, and debugging ease to ensure HIPAA compliance and reliable performance.
A mobile app development team uses a weighted decision matrix to prioritize backlog items like push notifications, offline mode, and social sharing. They assign weights based on user feedback and business goals to align on a roadmap that maximizes engagement and retention.
A gaming company developing a multiplayer game must choose between SQL and NoSQL databases for player data. They evaluate schema flexibility, scaling needs, and query patterns to support high write volumes and real-time interactions efficiently.
Companies use this skill to make technical decisions that reduce operational costs and improve scalability, such as selecting cloud services or third-party integrations. This helps optimize subscription-based revenue by ensuring reliable and maintainable software.
Consulting firms apply these frameworks to guide clients through architecture choices or tool selections, providing structured analysis and documentation. This enhances service value and leads to project-based or retainer revenue from informed decision-making.
Large organizations use this skill for internal projects, such as build vs buy decisions or library adoptions, to minimize risks and align teams. This supports revenue from software sales or internal cost savings through efficient resource allocation.
๐ฌ Integration Tip
Integrate this skill into team workflows by using the decision matrix template during sprint planning or architecture reviews to standardize choices and document ADRs for future reference.
Extract text from PDFs with OCR support. Perfect for digitizing documents, processing invoices, or analyzing content. Zero dependencies required.
Fast local PDF parsing with PyMuPDF (fitz) for Markdown/JSON outputs and optional images/tables. Use when speed matters more than robustness, or as a fallback while heavier parsers are unavailable. Default to single-PDF parsing with per-document output folders.
Find, evaluate, and recommend ClawHub skills by need with quality filtering and preference learning.
Fetch full tweets, long tweets, quoted tweets, and X Articles from X/Twitter without login or API keys, using no dependencies and zero configuration.
Skill ๆฅๆพๅจ | Skill Finder. ๅธฎๅฉๅ็ฐๅๅฎ่ฃ ClawHub Skills | Discover and install ClawHub Skills. ๅ็ญ'ๆไปไนๆ่ฝๅฏไปฅX'ใ'ๆพไธไธชๆ่ฝ' | Answers 'what skill can X', 'find a skill'. ่งฆๅ...
Generate QR codes from text or URL for mobile scanning.