[
  {
    "id": "boring-saas-api",
    "name": "Boring SaaS API stack",
    "description": "A conservative small-team stack for CRUD products, billing portals, dashboards, webhooks, background jobs, and Postgres-backed business software where shipping speed and hiring matter more than novelty.",
    "target_user": "small_team",
    "monthly_cost_estimate": "~£0–£40 before hosting/model usage",
    "languages": [
      "typescript",
      "javascript",
      "go",
      "python"
    ],
    "tools": [
      "vscode",
      "cursor",
      "github-copilot",
      "aider"
    ],
    "best_for": [
      "B2B SaaS, admin portals, Stripe webhooks, queues, and boring CRUD APIs",
      "Teams that want mainstream hiring, predictable libraries, and fast iteration"
    ],
    "avoid_if": [
      "Your core requirement is hard realtime, embedded constraints, or measured low-level performance rather than product throughput"
    ],
    "decision_triggers": [
      "Choose TypeScript when the same team owns frontend and backend boundaries",
      "Choose Go for simpler deployment and long-running service reliability when frontend sharing matters less",
      "Use Python for automation-heavy backends, data-adjacent workflows, or internal admin scripts"
    ],
    "notes": [
      "Default to TypeScript/JavaScript when UI and API work are tightly coupled; add Go only when service boundaries justify it.",
      "Defer Rust/C++/Zig until profiling shows a real bottleneck or safety/performance constraint.",
      "Use Decision Briefs or the public advisor flow for ranking — this stack is a starting template, not a live score."
    ]
  },
  {
    "id": "solo-agentic-coding",
    "name": "Solo agentic coding stack",
    "description": "A low-friction setup for solo builders who want AI-assisted implementation, refactors, tests, and documentation without committing to one expensive all-in-one environment.",
    "target_user": "solo_dev",
    "monthly_cost_estimate": "~£0–£30 plus optional API/model usage",
    "languages": [
      "typescript",
      "python"
    ],
    "tools": [
      "cursor",
      "aider",
      "continue",
      "ollama"
    ],
    "best_for": [
      "Solo founders, indie hackers, and technical operators shipping small web or automation products",
      "Developers who want a modular AI workflow that can mix hosted and local models"
    ],
    "avoid_if": [
      "You need centralized enterprise controls, audited model access, or a single vendor support contract from day one"
    ],
    "decision_triggers": [
      "Use an AI IDE for small edits, explanations, and navigation",
      "Use a CLI agent for larger test-driven refactors across multiple files",
      "Use local runtimes when privacy, cost control, or already-downloaded local models matter"
    ],
    "notes": [
      "Keep git as the coordination layer so agent edits are reviewable and reversible.",
      "Treat model/API spend as variable operating cost, not part of the fixed tool baseline.",
      "Pair with CacheSphere Decision Briefs before adding a new language to the repo."
    ]
  },
  {
    "id": "teaching-prototype",
    "name": "Teaching and prototype stack",
    "description": "A beginner-friendly stack for lessons, demos, small apps, and classroom experiments where instant feedback, readable syntax, and easy sharing beat production architecture.",
    "target_user": "education",
    "monthly_cost_estimate": "~£0–£20",
    "languages": [
      "python",
      "javascript",
      "typescript"
    ],
    "tools": [
      "replit",
      "vscode",
      "github-copilot",
      "zed"
    ],
    "best_for": [
      "Workshops, onboarding, bootcamps, demos, and early concept validation",
      "Projects where learners need visible results before deep infrastructure decisions"
    ],
    "avoid_if": [
      "The project already has strict production deployment, compliance, or performance requirements"
    ],
    "decision_triggers": [
      "Use Python for notebooks, automation, and approachable backend concepts",
      "Use JavaScript/TypeScript for browser-visible demos and interactive UI concepts",
      "Use hosted browser tooling when setup friction would derail the lesson"
    ],
    "notes": [
      "Optimize for confidence and concept transfer before enforcing production-grade structure.",
      "Graduate to the boring SaaS API stack when persistence, auth, billing, or team handoff become real.",
      "Keep examples small enough that students can understand every moving part.",
      "Prefer actively maintained free/low-cost editor AI (e.g. Zed, Copilot free tier) — Codeium/Windsurf ownership shifted after Cognition acquisition."
    ]
  },
  {
    "id": "data-insights-dashboard",
    "name": "Data insights dashboard stack",
    "description": "A practical stack for internal analytics dashboards, cohort exploration, product metrics, and notebook-driven decision support where Python, SQL, and a lightweight browser UI need to stay closely coupled.",
    "target_user": "analyst_builder",
    "monthly_cost_estimate": "~£0–£35 before hosting/data warehouse spend",
    "languages": [
      "python",
      "sql",
      "javascript",
      "typescript"
    ],
    "tools": [
      "vscode",
      "cursor",
      "github-copilot"
    ],
    "best_for": [
      "Internal BI dashboards, metric exploration, ad-hoc analysis, and notebook-to-app workflows",
      "Teams that need to move from pandas/Jupyter prototypes into a browser-visible interface without a big architecture jump"
    ],
    "avoid_if": [
      "You need heavy compliance controls, extremely large data volumes, or a dedicated BI platform from day one"
    ],
    "decision_triggers": [
      "Use Python for notebook exploration, data cleaning, and analysis glue",
      "Use SQL for warehouse queries, cohorts, and repeatable metrics definitions",
      "Use JavaScript/TypeScript for the dashboard shell when the interface must be interactive and browser-visible"
    ],
    "notes": [
      "Keep the analysis logic and dashboard logic close so metric definitions do not drift.",
      "Graduate to a heavier BI stack only when governance or scale demands it.",
      "This stack is meant to pressure-test internal dashboard recommendations before they grow into a full product surface."
    ]
  },
  {
    "id": "local-first-ai-coding",
    "name": "Local-first AI coding stack",
    "description": "A privacy-leaning coding setup for teams or individuals who want editor assistance, local model experiments, and reviewable agent workflows while minimizing dependence on hosted AI services.",
    "target_user": "solo_dev",
    "monthly_cost_estimate": "~£0 fixed; hardware and optional API fallback vary",
    "languages": [
      "python",
      "typescript",
      "go"
    ],
    "tools": [
      "vscode",
      "continue",
      "ollama",
      "aider"
    ],
    "best_for": [
      "Private repositories, environments that prefer local inference when online APIs are unavailable or restricted, and cost-sensitive coding assistance",
      "Teams that want to compare local/open-weight models against hosted assistants without changing editors"
    ],
    "avoid_if": [
      "You need best-in-class frontier model quality on every task and do not have local hardware headroom"
    ],
    "decision_triggers": [
      "Use local models for explanation, search, boilerplate, and low-risk refactors",
      "Use hosted fallback only for hard reasoning, large context, or production-critical changes",
      "Prefer languages with strong test tooling so local agent changes can be verified cheaply"
    ],
    "notes": [
      "Local-first does not mean local-only; keep a deliberate escalation path for hard tasks.",
      "Measure output quality and test pass rates rather than assuming local models are sufficient.",
      "Good fit for Python/TypeScript repositories where fast tests can bound agent mistakes."
    ]
  },
  {
    "id": "docs-static-site",
    "name": "Documentation and static site stack",
    "description": "A lightweight, low-maintenance stack for documentation sites, landing pages, README-driven guides, and small static projects where content matters more than dynamic backend logic.",
    "target_user": "solo_dev",
    "monthly_cost_estimate": "~£0–£20 before hosting",
    "languages": [
      "javascript",
      "typescript"
    ],
    "tools": [
      "vscode",
      "cursor",
      "github-copilot"
    ],
    "best_for": [
      "Documentation sites, README-driven guides, and knowledge bases",
      "Small landing pages and marketing microsites that rarely need a backend"
    ],
    "avoid_if": [
      "You need user accounts, real-time data, or a CMS with non-technical editors"
    ],
    "decision_triggers": [
      "Use Markdown and a static generator when the content is text-heavy and updates come from developers",
      "Add TypeScript only when you need interactive demos, search, or small UI widgets inside the docs",
      "Use VS Code with Copilot or Cursor when you want inline help while editing prose, configs, or front-matter"
    ],
    "notes": [
      "Keep hosting static (GitHub Pages, Cloudflare Pages, Netlify) so deployment stays a simple push.",
      "Treat search as a progressive enhancement; a static index or external search widget is often enough at small scale.",
      "Pair with CacheSphere Decision Briefs before adding a backend or auth layer — most doc sites do not need one."
    ]
  },
  {
    "id": "systems-programming-starter",
    "name": "Systems programming starter stack",
    "description": "A cautious layout for teams exploring performance-sensitive components, FFI boundaries, or toolchain-heavy native code while keeping day-to-day services boring and testable.",
    "target_user": "small_team",
    "monthly_cost_estimate": "~£0–£50 before hardware/cloud spend",
    "languages": [
      "rust",
      "go",
      "cpp"
    ],
    "tools": [
      "vscode",
      "cursor",
      "github-copilot",
      "aider"
    ],
    "best_for": [
      "Greenfield modules where memory safety or predictable latency matters more than fastest prototype iteration",
      "Teams that already ship higher-level services but need a disciplined native lane for hotspots"
    ],
    "avoid_if": [
      "The problem is primarily CRUD, dashboards, or web-first throughput with no measured native bottleneck"
    ],
    "decision_triggers": [
      "Use Rust when ownership and aliasing rules should bound memory bugs without a GC pause budget",
      "Use Go for straightforward services, tooling CLIs, and concurrency-heavy glue around those native modules",
      "Use C++ only when an existing toolchain, SDK, or ecosystem constraint already anchors you there"
    ],
    "notes": [
      "Treat native code as an integration boundary: narrow FFI surfaces, broad tests, and telemetry before optimizing.",
      "Pair native exploration with CacheSphere Decision Briefs so staffing and maintenance assumptions stay explicit.",
      "Defer exotic languages until profiling proves the bottleneck is not algorithmic or I/O-bound."
    ]
  }
]
