| name | adv-backend-stack-eval |
| description | Backend technology stack evaluation — choose boring technology scaled by project context. Use when selecting languages, databases, async infra, or API styles for new or existing backends. |
| keywords | ["backend","stack","backend stack","tech stack","architecture","database","postgres","data store","queue","kafka","temporal","async","message queue","graphql","rpc","rest","api","rust","go","python","typescript","language","runtime","choose boring technology","technology choice","innovation budget","boring technology","stack evaluation","architecture decision"] |
| license | MIT |
| metadata | {"review_status":"reviewed","source":"agent-created","trigger_change":"createbackendstackevaluationsk","created_at":"2026-05-08"} |
Backend Stack Evaluation Skill
When to Load
Load when evaluating backend language/runtime, database/data layer, async/workflow infrastructure, or API style.
Load when starting a backend/API, adding/replacing a data store/queue/runtime, or comparing stack options.
Skip when stack is already mandated, decision is trivial/reversible, only one viable option exists, or user already chose and wants implementation help.
Guiding Principle
Prefer boring, well-understood technology when evidence is comparable. Scale novelty tolerance by project context: personal projects can experiment; platforms need strong evidence for change.
"Every company gets about three innovation tokens." — Dan McKinley, Choose Boring Technology
Project-Type Spectrum
| Type | Context | Innovation Budget | Evidence Bar |
|---|
| Personal / scratch | usually greenfield | high | Light |
| Internal tool | greenfield or brownfield | medium | Standard |
| Published product / SaaS | hybrid | low | Standard |
| Platform / library | brownfield-sensitive | very low | Rigorous |
For brownfield work, existing-stack integration is first-class. Do not treat greenfield appeal as automatic migration fit.
Quick Adoption Check
Ask 2–3, weighted by project type:
- Has team shipped this tech in production before?
- Are needed libraries maintained and ecosystem-standard?
- Can team debug it at 3 AM with current tooling?
- Do compliance, residency, encryption, or audit needs constrain choice?
Dimension Docs
| Doc | Use |
|---|
LANGUAGE.md | Language/runtime criteria and prompts |
DATABASE.md | Database/data layer criteria and prompts |
ASYNC.md | Queue/event/workflow criteria and prompts |
API.md | REST/RPC/GraphQL/API contract criteria and prompts |
Evidence Bar
| Tier | Requirement |
|---|
| Light | Docs checked, active maintenance, gut check passes |
| Standard | Light + production examples, maintenance health, primary failure mode, migration path |
| Rigorous | Standard + migration plan, runbooks, ops capability, alternatives, capacity estimate |
Before recommending, state tier, evidence present, missing evidence, and risks. Do not invent certainty.
Research Tools
- Context7 — official docs, API references.
- Exa — ecosystem sentiment, production case studies, CVE status.
- Exa → searchcode — use Exa to find candidate repos, then searchcode code search / file fetch for real-world usage and adoption patterns.
Hand-offs + Boundaries
- Use
prioritizer when 2+ options remain viable and tradeoffs depend on values.
- Use
adv-user-intuit when concrete candidates need user taste/preference.
- Defer frontend/fullstack defaults to
sharperflow-web-standards.
- Defer MCP tool choice to
mcp-selection.
- Adjacent but out-of-scope: cloud provider, CI/CD, observability platform, cache/CDN, secrets platform.
Sources
