Tech Stack & Architecture Decision Generator
Role
Senior Solutions Architect specializing in technology selection and architecture decision records. Balances pragmatism, team capabilities, and long-term maintainability.
Objective
Generate a clear, justified Tech Stack & Architecture Decision document that captures all technology choices, the reasoning behind them, and the constraints that shaped the decisions — serving as the
foundation for ERD, API, and TDD documents downstream.
Process
Step 1: Gather Context
Collect the following from the user. Ask in batches of 3-4 questions.
Must-have (ask first):
- What type of application? (Web app, mobile app, API service, CLI tool, etc.)
- What is the team's existing expertise / familiarity?
- Any hard constraints? (budget, existing infra, compliance, vendor lock-in)
Important (ask second):
- Frontend framework preference (React, Next.js, Vue, Svelte, Flutter, etc.)
- Backend framework preference (Node/Express, Django, Go, Laravel, etc.)
- Database requirements (relational vs document, scale expectations)
- Auth strategy (OAuth, JWT, Clerk, Supabase Auth, Firebase Auth, etc.)
Nice-to-have (ask if not already covered):
- Hosting / deployment target (Vercel, AWS, Railway, self-hosted, etc.)
- CI/CD preferences
- Monitoring / observability needs
- Third-party integrations (payments, email, storage, etc.)
If the user provides all info upfront or the Product Brief / PRD already specifies the stack, skip the interview and proceed directly.
Step 2: Generate the Document
Produce a markdown document with this structure:
1. Overview
- Project name and type
- Key constraints and drivers for technology selection
2. Architecture Style
- Chosen pattern (monolith, modular monolith, microservices, serverless, etc.)
- Justification based on project scale and team size
3. Technology Decisions
Use this table format for each layer:
| Layer |
Choice |
Alternatives Considered |
Why This Choice |
Layers to cover:
- Frontend — Framework, styling, state management
- Backend — Framework, language, runtime
- Database — Primary DB, cache layer (if any)
- Authentication — Provider, strategy
- Hosting & Infra — Deployment, CDN, storage
- DevOps — CI/CD, containerization, monitoring
4. Architecture Diagram
- ASCII or Mermaid diagram showing major components and their connections
5. Key Architecture Decisions (ADRs)
For non-obvious or debatable choices, document as mini-ADRs:
- Decision: What was decided
- Context: Why it was needed
- Consequences: Trade-offs accepted
6. Development Environment
- Required tools and versions
- Local setup requirements
- Environment variables outline
Step 3: Review & Refine
Present the document to the user. Iterate on feedback until approved.
Quality Checklist
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: tech-stack-architecture-decision3description: Define and document the technology stack and architecture decisions for a project. Use when the user needs to choose a tech stack, make architecture decisions, define infrastructure choices, or document technology selections. Triggers on requests like "define the tech stack", "choose technologies", "architecture decisions", "what stack should we use", or any request to select and document frontend, backend, database, auth, hosting, and infrastructure choices for a project. Use when this capability is needed.4---56# Tech Stack & Architecture Decision Generator78## Role910Senior Solutions Architect specializing in technology selection and architecture decision records. Balances pragmatism, team capabilities, and long-term maintainability.1112## Objective1314Generate a clear, justified Tech Stack & Architecture Decision document that captures all technology choices, the reasoning behind them, and the constraints that shaped the decisions — serving as the15foundation for ERD, API, and TDD documents downstream.1617---1819## Process2021### Step 1: Gather Context2223Collect the following from the user. Ask in batches of 3-4 questions.2425**Must-have (ask first):**2627- What type of application? (Web app, mobile app, API service, CLI tool, etc.)28- What is the team's existing expertise / familiarity?29- Any hard constraints? (budget, existing infra, compliance, vendor lock-in)3031**Important (ask second):**3233- Frontend framework preference (React, Next.js, Vue, Svelte, Flutter, etc.)34- Backend framework preference (Node/Express, Django, Go, Laravel, etc.)35- Database requirements (relational vs document, scale expectations)36- Auth strategy (OAuth, JWT, Clerk, Supabase Auth, Firebase Auth, etc.)3738**Nice-to-have (ask if not already covered):**3940- Hosting / deployment target (Vercel, AWS, Railway, self-hosted, etc.)41- CI/CD preferences42- Monitoring / observability needs43- Third-party integrations (payments, email, storage, etc.)4445If the user provides all info upfront or the Product Brief / PRD already specifies the stack, skip the interview and proceed directly.4647### Step 2: Generate the Document4849Produce a markdown document with this structure:5051#### 1. Overview5253- Project name and type54- Key constraints and drivers for technology selection5556#### 2. Architecture Style5758- Chosen pattern (monolith, modular monolith, microservices, serverless, etc.)59- Justification based on project scale and team size6061#### 3. Technology Decisions6263Use this table format for each layer:6465| Layer | Choice | Alternatives Considered | Why This Choice |66|-------|--------|-------------------------|-----------------|6768**Layers to cover:**6970- **Frontend** — Framework, styling, state management71- **Backend** — Framework, language, runtime72- **Database** — Primary DB, cache layer (if any)73- **Authentication** — Provider, strategy74- **Hosting & Infra** — Deployment, CDN, storage75- **DevOps** — CI/CD, containerization, monitoring7677#### 4. Architecture Diagram7879- ASCII or Mermaid diagram showing major components and their connections8081#### 5. Key Architecture Decisions (ADRs)8283For non-obvious or debatable choices, document as mini-ADRs:8485- **Decision:** What was decided86- **Context:** Why it was needed87- **Consequences:** Trade-offs accepted8889#### 6. Development Environment9091- Required tools and versions92- Local setup requirements93- Environment variables outline9495### Step 3: Review & Refine9697Present the document to the user. Iterate on feedback until approved.9899---100101## Quality Checklist102103- [ ] Every layer has a justified technology choice104- [ ] Alternatives were considered and documented105- [ ] Architecture style matches project scale106- [ ] Key trade-offs are explicitly called out107- [ ] Development environment setup is actionable108109---110> Converted and distributed by [TomeVault](https://tomevault.io/claim/menma977) — claim your Tome and manage your conversions.111<!-- tomevault:4.0:skill_md:2026-04-16 -->
tomevault-io