Skip to main content

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.

Mantra

Happy customers pay the bills

Framing Questions​

Before evaluating any technology, run through these prompts drawn from the question types:

Question TypeTech Stack Prompt
SystemsHow does this tool connect to our existing stack? What dependencies does it create?
AgencyWhat do we control with this choice? What do we give up?
FutureWhat becomes possible in 2 years that isn't possible today?
RealityWhat's the real problem we're solving—speed, scale, or skill gap?
PossibilitiesWhat 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. DX Validation (Can we test it?)​

  • Can you run tests without hitting external APIs?
  • Does CI pass on first clone? (env setup, service deps, auth tokens)
  • What fails first — and does it fail fast with a clear message?
  • Can you replicate prod config in staging without manual sync?
  • What's the cold-start time for a new developer to run the full test suite?

This is the gate most teams skip. A tool that scores well on features but breaks in CI costs more than one with fewer features that tests cleanly. See Identity Auth evaluation for a worked example.

9. 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

10. Post-Adoption (When it breaks)​

Selection is one decision. Living with it is a thousand. When the tool you picked breaks in CI:

StepQuestionAction
1Env correct?Validate all required vars exist before init. Fail in <5s, not 45s
2Your code or theirs?Isolate: does the vendor's own example reproduce the failure?
3Flaky or broken?Run 3x. If 1/3 pass, it's timing/race. If 0/3, it's config
4Version drift?Check package.json version against vendor's changelog for breaking changes
5Workaround or migrate?If workaround count exceeds 3, re-evaluate against alternatives

The pattern: Most post-adoption pain is DX friction (env setup, test reliability, CI flakes) not feature gaps. Track workaround count — it's the leading indicator that a migration conversation is needed.

LLM Selection​

Which model for which job? Apply situational wisdom — state of task + state of constraints = model choice.

State of Task​

Cognitive DemandExamplesWhat You Need
Deep reasoningArchitecture, complex refactors, multi-file changesHighest capability, thinking tokens
Broad analysisRepo-wide audits, legacy migration, pattern searchMassive context window
Feature buildingNew endpoints, components, test suitesBalanced reasoning + speed
Quick fixesTypos, simple generation, formattingSpeed and cost efficiency
VerificationCode review, second opinion, fact-checkingDifferent model family (avoid marking own homework)

State of Constraints​

ConstraintFavoursAvoids
Budget-limitedFree tiers (Gemini), cheap models (Haiku, Flash)Opus for commodity tasks
Time-pressuredFast models, parallel agentsSequential deep reasoning
Context-heavyLarge context windows (Gemini 1M+)Small-window models on big repos
Accuracy-criticalBest available + verification agentFast models without review
ExploratoryCheap models with high throughputExpensive models for brainstorming

Model Decision Matrix​

TaskPrimaryWhyFallback
Architecture, complex planningClaude OpusDeepest reasoning, thinking tokenso3 for mathematical/logical problems
Feature implementationClaude SonnetBalanced speed/quality, tool integrationGPT-4o
Repo-wide analysisGemini Pro1M+ token context, free tierClaude with chunked context
Quick fixes, batch tasksClaude Haiku / Gemini FlashSpeed, costSonnet if quality insufficient
Code reviewDifferent family than writerAvoid confirmation biasIf Claude wrote it, review with Gemini or GPT
Content generationClaude (any tier) + voice agentsBest at following complex voice instructions—
UI prototypingv0.dev / CursorVisual feedback loop, component focusClaude 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​

Radar​