Tech Stack Decisions
Software's job is to help people solve problems that create real world value.
Understand the job to be done to determine required functions and desired outcomes.
Happy customers pay the bills
Framing Questions
Before evaluating any technology, run through these prompts drawn from the question types:
| Question Type | Tech Stack Prompt |
|---|---|
| Systems | How does this tool connect to our existing stack? What dependencies does it create? |
| Agency | What do we control with this choice? What do we give up? |
| Future | What becomes possible in 2 years that isn't possible today? |
| Reality | What's the real problem we're solving—speed, scale, or skill gap? |
| Possibilities | What options haven't we considered? Who else has solved this? |
Checklist
Good decisions follow good questions. The quality of your tech choices depends on the quality of questions you ask first.
1. Problem (What are we solving?)
- What's the core job to be done?
- What does success look like in 6 months? 2 years?
- What type of system is this? (CRUD, real-time, batch, analytics, offline-first)
2. Constraints (What narrows the field?)
- Regulatory requirements? (PII, compliance, data residency)
- Budget ceiling?
- Timeline to production?
- What must it integrate with?
3. Requirements (What must it do?)
- Non-functional priorities ranked: latency, throughput, consistency, availability, security
- Expected scale: users, requests/sec, data volume
- Who owns the data? Who owns the intelligence?
4. Options (What exists?)
- What's the proven pattern for this class of problem?
- Who else has solved this? What did they use?
- What are the 2-3 viable candidates?
5. Team Fit (Can we execute?)
- Do we have the skills? Realistic learning curve?
- How hard is hiring for this stack?
- Community health: active releases, clear roadmap, low bus factor?
- Tooling: IDE support, testing frameworks, CI/CD story?
6. Economics (Total cost of ownership)
- Infrastructure + licenses + support at scale?
- Development velocity impact?
- Maintenance burden over time?
- Lock-in risk? Exit cost if we need to move?
7. Risk (What happens when things go wrong?)
- Failure modes: partial outages, network splits, dependency failures?
- Backup/restore, migrations, rollback patterns?
- Security posture: auth, encryption, patch cadence?
8. Validation (Before committing)
- Can we spike the core flow in a day?
- How painful is migration if we're wrong in 12 months?
- Write the decision record: options, trade-offs, why this choice now
LLM Selection
Which model for which job? Apply situational wisdom — state of task + state of constraints = model choice.
State of Task
| Cognitive Demand | Examples | What You Need |
|---|---|---|
| Deep reasoning | Architecture, complex refactors, multi-file changes | Highest capability, thinking tokens |
| Broad analysis | Repo-wide audits, legacy migration, pattern search | Massive context window |
| Feature building | New endpoints, components, test suites | Balanced reasoning + speed |
| Quick fixes | Typos, simple generation, formatting | Speed and cost efficiency |
| Verification | Code review, second opinion, fact-checking | Different model family (avoid marking own homework) |
State of Constraints
| Constraint | Favours | Avoids |
|---|---|---|
| Budget-limited | Free tiers (Gemini), cheap models (Haiku, Flash) | Opus for commodity tasks |
| Time-pressured | Fast models, parallel agents | Sequential deep reasoning |
| Context-heavy | Large context windows (Gemini 1M+) | Small-window models on big repos |
| Accuracy-critical | Best available + verification agent | Fast models without review |
| Exploratory | Cheap models with high throughput | Expensive models for brainstorming |
Model Decision Matrix
| Task | Primary | Why | Fallback |
|---|---|---|---|
| Architecture, complex planning | Claude Opus | Deepest reasoning, thinking tokens | o3 for mathematical/logical problems |
| Feature implementation | Claude Sonnet | Balanced speed/quality, tool integration | GPT-4o |
| Repo-wide analysis | Gemini Pro | 1M+ token context, free tier | Claude with chunked context |
| Quick fixes, batch tasks | Claude Haiku / Gemini Flash | Speed, cost | Sonnet if quality insufficient |
| Code review | Different family than writer | Avoid confirmation bias | If Claude wrote it, review with Gemini or GPT |
| Content generation | Claude (any tier) + voice agents | Best at following complex voice instructions | — |
| UI prototyping | v0.dev / Cursor | Visual feedback loop, component focus | Claude with frontend-design skill |
The Anti-Pattern
Using the best model for everything. Opus for a typo fix wastes money. Haiku for architecture wastes time. Match capability to demand.
TASK COMPLEXITY × REVERSIBILITY = MODEL TIER
High complexity + irreversible → Best available (Opus, o3)
High complexity + reversible → Mid-tier (Sonnet, GPT-4o)
Low complexity + any → Fast/cheap (Haiku, Flash)
Cross-Model Verification
The strongest pattern: write with one model family, verify with another. Models share training biases within families. A Claude review of Claude code catches fewer issues than a Gemini review of Claude code.
See Config Architecture for how we configure multiple agents on the same codebase without duplicating context.
Context
- AI Coding Config — Agent-agnostic setup with decision log
- Situational Wisdom — Context-dependent decisions
- Blockchain Decisions
- Decision Frameworks
- Decision Journal
- SaaS Products