← Build log

The Risk Assessment Framework: How to Compare Features Before You Build Them

January 2025
RiskAssessmentProductStrategySoloBuilderDecisionFrameworkFeatureComparisonShipSmart

Why we created parallel risk assessments for auto-recovery and live transcription—and how comparing them side-by-side revealed the obvious choice

Published: January 2025
Tags: #RiskAssessment #ProductStrategy #SoloBuilder #DecisionFramework #FeatureComparison #ShipSmart

The “So What?” - Stop Guessing Which Feature to Build Next

Bottom Line Value: Learn how to create structured risk assessments for competing features so you can make confident prioritization decisions based on data, not gut feel.

What You’ll Gain:

  • A practical risk assessment template for evaluating features
  • Real example: Side-by-side comparison of auto-recovery vs. live transcription
  • How to score features across 7 risk dimensions
  • The “weighted decision matrix” for objective feature prioritization
  • When MEDIUM risk is acceptable vs. when it’s a blocker
  • ROI: Make confident feature decisions in hours instead of weeks of debate

Who This Helps: Solo builders and technical product managers who struggle with feature prioritization and need a structured framework for comparing options.

Why Bother: Every week you spend debating which feature to build is a week you’re not shipping. This framework helps you make confident decisions quickly with clear, documented reasoning.

TLDR: Parallel Risk Assessments Reveal the Obvious Choice

We had two features ready to build. Both had complete technical architecture. Both would add value. We needed to choose which to build first.

The Process:

  1. Created comprehensive risk assessment for auto-recovery
  2. Created comprehensive risk assessment for live transcription
  3. Compared them side-by-side across 7 dimensions
  4. The choice became obvious

The Result:

Risk CategoryAuto-RecoveryLive Transcription
Technical Complexity🟢 LOW🟡 MEDIUM
Integration Complexity🟢 LOW🟡 MEDIUM
Performance Impact🟢 LOW🟡 MEDIUM
User Value🔴 CRITICAL🟡 HIGH
Timeline3 weeks3-5 weeks
Overall Risk🟢 LOW🟡 MEDIUM

Decision: Ship auto-recovery first (v1.0), then live transcription (v1.1)

Time to decision: 2 hours of structured analysis vs. weeks of debate

The Problem: Gut Feel Doesn’t Scale

Here’s what usually happens when you have multiple features to choose from:

The Endless Debate

Monday: “Let’s build live transcription! Users will love seeing text as they speak!”

Tuesday: “Wait, auto-recovery is more critical. What if users lose their work?”

Wednesday: “But live transcription is a competitive differentiator…”

Thursday: “But auto-recovery builds trust…”

Friday: “I still don’t know which to build first.”

The Gut Feel Trap

What We Tell Ourselves:

  • “This one feels more important”
  • “Users probably want this more”
  • “This seems less risky”
  • “This looks easier to build”

The Problem:

  • Feelings change day to day
  • “Probably” isn’t data
  • “Seems” isn’t analysis
  • “Looks” isn’t estimation

The Result:

  • Decision paralysis
  • Weeks of debate
  • No features shipped
  • Anxiety about making the wrong choice

The Breakthrough: Structured Risk Assessment

Here’s what changed everything: Create parallel risk assessments and compare them side-by-side.

The Template: 7 Risk Dimensions

For each feature, evaluate:

  1. Technical Complexity - How hard is the code?
  2. Integration Complexity - How many systems does it touch?
  3. Performance Impact - Will it slow things down?
  4. Testing Complexity - How hard is it to test?
  5. UX Impact - Does it add friction?
  6. Maintenance Burden - How much ongoing work?
  7. Timeline Impact - How long will it take?

For each dimension, assign:

  • 🟢 LOW - Minimal risk, well-understood
  • 🟡 MEDIUM - Some risk, manageable
  • 🔴 HIGH - Significant risk, needs mitigation

The Process: Document Everything

Step 1: Create Individual Assessments

For each feature, write a comprehensive risk assessment document:

# Feature X - Risk Assessment

## Technical Complexity: 🟢 LOW

**Why:**

- Builds on existing infrastructure
- No new dependencies
- Well-understood patterns

**Evidence:**

- Similar feature took 2 weeks
- Team has experience with this
- Clear implementation path

## Integration Complexity: 🟡 MEDIUM

**Why:**

- Touches 3 systems
- Requires coordination
- Some unknowns

**Mitigation:**

- Prototype integration first
- Test each touchpoint
- Feature flag for rollback

Step 2: Compare Side-by-Side

Create a comparison table:

Risk CategoryFeature AFeature B
Technical🟢 LOW🟡 MEDIUM
Integration🟢 LOW🟡 MEDIUM
Performance🟢 LOW🟡 MEDIUM
Testing🟡 MEDIUM🟡 MEDIUM
UX🟢 LOW🔴 HIGH
Maintenance🟢 LOW🟡 MEDIUM
Timeline3 weeks5 weeks

Step 3: Calculate Overall Risk

Count the risk levels:

  • Feature A: 5 LOW, 1 MEDIUM, 0 HIGH = LOW RISK
  • Feature B: 0 LOW, 5 MEDIUM, 1 HIGH = MEDIUM-HIGH RISK

Step 4: Make the Decision

The choice becomes obvious when you see it laid out.

Real Example: Auto-Recovery vs. Live Transcription

Here’s the actual analysis we did:

Auto-Recovery Risk Assessment

Technical Complexity: 🟢 LOW

Why:

  • Builds on existing checkpoint system (already working)
  • Uses existing transcription engine
  • Simple linear flow (detect → assemble → transcribe → save)
  • No concurrent processing
  • ~530 lines of new code

Evidence:

  • Checkpoint system proven stable
  • Similar recovery logic in other apps
  • Clear implementation path

Integration Complexity: 🟢 LOW

Why:

  • Runs once at app startup (isolated)
  • Doesn’t touch recording flow
  • Doesn’t affect transcription pipeline
  • Non-blocking (background processing)

Evidence:

  • App startup is well-understood
  • SessionStorage already exists
  • IPC handlers are simple

Performance Impact: 🟢 LOW

Why:

  • Runs in background on startup
  • Only processes if recovery needed
  • No impact on normal operation
  • User doesn’t notice

Evidence:

  • Recovery happens before user interacts
  • Transcription is already async
  • No UI blocking

Testing Complexity: 🟡 MEDIUM

Why:

  • Requires simulating crashes
  • Need to test multiple scenarios
  • Timing-dependent (startup sequence)

Mitigation:

  • Create crash simulation script
  • Test on multiple OS versions
  • Automated crash recovery tests

UX Impact: 🟢 LOW

Why:

  • Completely invisible during normal operation
  • Only appears after crash (rare)
  • Positive impact (prevents data loss)
  • No friction added

Evidence:

  • Zero changes to normal workflow
  • No new UI elements (unless recovery needed)
  • No user decisions required

Maintenance Burden: 🟢 LOW

Why:

  • Small, focused codebase (~530 lines)
  • Simple logic (no complex state)
  • Runs infrequently (only after crash)
  • Easy to debug

Evidence:

  • Similar features are low-maintenance
  • Clear error handling
  • Good logging

Timeline Impact: 3 weeks

Breakdown:

  • Week 1: Backend (CheckpointRecoveryManager)
  • Week 2: Frontend (RecoveryNotification)
  • Week 3: Integration & Testing

Confidence: HIGH (well-scoped, clear requirements)

Overall Risk: 🟢 LOW

Summary: 5 LOW, 1 MEDIUM, 0 HIGH

Recommendation: ✅ Ship in v1.0

Live Transcription Risk Assessment

Technical Complexity: 🟡 MEDIUM

Why:

  • File watching system (new dependency: chokidar)
  • Background transcription queue (concurrent processing)
  • Real-time UI updates (IPC events during recording)
  • State management (partial transcripts, queue state)
  • Chunk assembly logic (handling overlaps)

Evidence:

  • More complex than auto-recovery
  • Concurrent processing is harder to debug
  • More moving parts

Integration Complexity: 🟡 MEDIUM

Why:

  • Integrates with active recording flow (not just startup)
  • Requires coordination between Swift and Node.js
  • Real-time IPC communication (performance sensitive)
  • Must not interfere with recording quality

Evidence:

  • Recording flow is critical path
  • Performance impact on recording is risky
  • More integration points than auto-recovery

Performance Impact: 🟡 MEDIUM

Why:

  • Background transcription uses CPU during recording
  • +20-30% CPU usage
  • +50-100MB memory usage
  • File watching adds I/O overhead

Mitigation:

  • CPU throttling for transcription
  • Queue limits (max 2 concurrent)
  • Batch UI updates (every 5 seconds)
  • Performance testing on low-end hardware

Testing Complexity: 🟡 MEDIUM

Why:

  • Concurrent operations (harder to test)
  • Timing-dependent behavior
  • Real-time UI updates (harder to verify)
  • Edge cases (fast checkpoints, slow transcription)

Evidence:

  • Need to test race conditions
  • Timing issues are hard to reproduce
  • More test scenarios than auto-recovery

UX Impact: 🔴 HIGH (BLOCKING)

Why:

  • UX design not finalized
  • User enablement method undecided
  • Live transcript display location undecided
  • Auto-paste behavior undecided
  • Potential friction to current workflow

Blocking Issues:

  1. How do users enable this feature?
  2. Where does live transcript appear?
  3. Auto-paste live or wait until end?
  4. User testing needed

Evidence:

  • Can’t explain UX in one sentence
  • Multiple open questions
  • Risk of adding friction

Maintenance Burden: 🟡 MEDIUM

Why:

  • More complex codebase (~530 lines, but intricate)
  • Concurrent processing (harder to debug)
  • External dependency (chokidar)
  • Real-time updates (timing-sensitive)

Evidence:

  • File watchers can break with OS updates
  • Queue logic may need tuning
  • More potential failure modes

Timeline Impact: 3-5 weeks

Breakdown:

  • Week 1: Proof of Concept (validate performance)
  • Week 2-3: Backend implementation
  • Week 4: Frontend implementation
  • Week 5: Optimization & testing

Confidence: MEDIUM (UX design needed first)

Overall Risk: 🟡 MEDIUM (with 🔴 HIGH UX blocker)

Summary: 0 LOW, 5 MEDIUM, 1 HIGH

Recommendation: ❌ Design UX first, implement in v1.1

The Comparison: Side-by-Side

Risk CategoryAuto-RecoveryLive TranscriptionWinner
Technical Complexity🟢 LOW (simple flow)🟡 MEDIUM (concurrent)Auto-recovery
Integration Complexity🟢 LOW (startup only)🟡 MEDIUM (during recording)Auto-recovery
Performance Impact🟢 LOW (background)🟡 MEDIUM (+30% CPU)Auto-recovery
Testing Complexity🟡 MEDIUM (crash sim)🟡 MEDIUM (timing)Tie
UX Impact🟢 LOW (invisible)🔴 HIGH (undecided)Auto-recovery
Maintenance Burden🟢 LOW (simple)🟡 MEDIUM (complex)Auto-recovery
Timeline3 weeks3-5 weeksAuto-recovery
User Value🔴 CRITICAL (safety)🟡 HIGH (delight)Auto-recovery
Overall Risk🟢 LOW🟡 MEDIUMAuto-recovery

Score: Auto-recovery wins 7 out of 8 categories

Decision: Ship auto-recovery first (v1.0), then live transcription (v1.1)

Confidence: VERY HIGH (clear winner across all dimensions)

The Decision Matrix: Weighted Scoring

For even more rigor, assign weights to each category:

Risk CategoryWeightAuto-Recovery ScoreLive Transcription Score
User Value1010 (critical)8 (high)
Technical Risk99 (low)6 (medium)
UX Impact99 (invisible)3 (undecided)
Timeline88 (3 weeks)6 (3-5 weeks)
Performance79 (minimal)6 (medium)
Maintenance79 (simple)6 (complex)
Testing67 (medium)7 (medium)

Weighted Scores:

  • Auto-Recovery: 8.9/10
  • Live Transcription: 6.4/10

Gap: 2.5 points (significant)

Decision: Auto-recovery is the clear winner

The Takeaway: Data Beats Gut Feel

Before Risk Assessment:

  • “Both features seem good”
  • “Hard to choose”
  • “Let’s debate for a few weeks”

After Risk Assessment:

  • “Auto-recovery wins 7 out of 8 categories”
  • “Weighted score: 8.9 vs 6.4”
  • “Decision is obvious”

Time Investment:

  • 2 hours to create both assessments
  • 30 minutes to compare side-by-side
  • 10 minutes to make decision

Result:

  • Clear, documented decision
  • Confidence in the choice
  • No second-guessing
  • Ready to ship

The Framework: How to Do This Yourself

Step 1: Create Risk Assessment Template

# [Feature Name] - Risk Assessment

## Technical Complexity: [🟢/🟡/🔴]

**Why:** [Explanation]
**Evidence:** [Data points]

## Integration Complexity: [🟢/🟡/🔴]

**Why:** [Explanation]
**Evidence:** [Data points]

## Performance Impact: [🟢/🟡/🔴]

**Why:** [Explanation]
**Mitigation:** [If needed]

## Testing Complexity: [🟢/🟡/🔴]

**Why:** [Explanation]
**Strategy:** [Test plan]

## UX Impact: [🟢/🟡/🔴]

**Why:** [Explanation]
**Friction:** [Assessment]

## Maintenance Burden: [🟢/🟡/🔴]

**Why:** [Explanation]
**Long-term:** [Considerations]

## Timeline Impact: [X weeks]

**Breakdown:** [Phase by phase]
**Confidence:** [HIGH/MEDIUM/LOW]

## Overall Risk: [🟢/🟡/🔴]

**Summary:** [Risk count]
**Recommendation:** [Ship/Delay/Cancel]

Step 2: Fill Out for Each Feature

Spend 1-2 hours per feature doing honest assessment.

Step 3: Compare Side-by-Side

Create comparison table with all dimensions.

Step 4: Calculate Scores

Count risk levels and calculate weighted scores if needed.

Step 5: Make Decision

The data will make the choice obvious.

Conclusion: Structure Enables Speed

The Paradox:

Spending 2 hours on structured risk assessment feels slower than “just deciding.” But it’s actually 10x faster than weeks of debate.

The Benefit:

  • Clear, documented reasoning
  • Confidence in the decision
  • No second-guessing
  • Team alignment (if you have one)
  • Future reference (why did we choose this?)

The Discipline:

Don’t skip the assessment because you “already know” which feature to build. Your gut might be right, but the assessment will either confirm it (confidence) or reveal blind spots (course correction).

The Result:

Ship the right features in the right order with confidence.

Next in this series: How we designed auto-recovery to be completely invisible (implementation details)