← Build log

The Last-Mile Feature Problem: How We Added Recording Mode Indicators Without Breaking Anything

Sometimes the smallest changes carry the biggest risk. There’s a brutal irony in software development: the closer you get to production-ready, the more dangerous even tiny features become. Your users love your app, your codebase is stable, and then someone asks for one little visual indicator…

“Can we just show which recording mode is active? Like a tiny badge or something? It should be easy, right?”

Famous last words.

This is the story of how we delivered a surgical MVP for recording mode indicators in VoiceCatcher without touching anything that didn’t need touching. No rewrites, no new state management systems, no architectural pivots. Just surgical precision and a healthy fear of breaking things users love.

TLDR - What You’ll Gain

What: A methodology for adding “small” features to beloved software without user trauma Time Investment: 2 hours for implementation vs. 20+ hours for comprehensive feature builds
Business Value: Maintain user trust while delivering iterative improvements Risk Level: Minimal - easily reversible with surgical change isolation When to Use: When users love your current experience but need incremental enhancements Bottom Line: You can add polish without breaking the magic that made users fall in love with your app

The Feature Request That Shouldn’t Be Hard

We had VoiceCatcher working beautifully. Users loved the recording button, the neumorphic design, the elegant simplicity. But we’d recently added manual recording mode (Ctrl+Shift+R bypasses silence detection) alongside the original auto mode (Ctrl+R with silence detection).

The feedback was immediate: “I can’t tell which mode I’m in when recording starts.”

Fair point. When you’re actively recording, you want to know if the app will stop automatically or if you need to manually stop it. That’s not a nice-to-have - that’s core UX.

But here’s where it gets dangerous. VoiceCatcher’s UI is beloved. When users describe software as “beautiful” and “elegant,” you don’t mess with that lightly. The recording button is the centerpiece - clean, neumorphic, perfect visual feedback states. One wrong move and you’ve broken the thing people actually love about your app.

So how do you add a mode indicator without destroying the beauty that got you here?

The Surgical MVP Philosophy

Here’s what I’ve learned building production software: the last 10% of polish carries 90% of the risk of breaking something users love.

Traditional approach: Design the complete feature. Build robust state management. Create comprehensive mode switching. Add extensive configuration options. Ship the Porsche.

Surgical MVP approach: Find the absolute minimal change that solves 80% of the problem. Use existing infrastructure. Make it easily removable. Ship the skateboard.

For our recording mode indicators, the surgical approach meant:

  1. Leverage existing recording state - Don’t create new state management
  2. Use established visual patterns - Follow the same state-based styling the recording button already uses
  3. Show only when needed - Display mode badges only during active recording
  4. Match existing design system - Use our neumorphic styles, colors, and typography
  5. Make it reversible - If users hate it, removal should be trivial

The key insight: the recording button already changes appearance when recording starts. We just needed to piggyback on that existing pattern.

The Implementation: 30 Lines of Surgical Code

Instead of building a comprehensive mode management system, we added exactly three things:

1. Track Current Recording Mode (4 lines)

const [currentRecordingMode, setCurrentRecordingMode] = useState<'auto' | 'manual'>('auto');

2. Capture Mode When Recording Starts (IPC Extension)

// Backend: Include mode in recording status events
this.notifyAllWindows('recording-status-changed', { status: 'recording', mode });

// Frontend: Extract mode from status updates
const unregisterRecordingListener = window.electronAPI.onRecordingStatusChanged((status, mode) => {
  if (status === 'recording' && mode) {
    setCurrentRecordingMode(mode);
  }
});

3. Show Mode Badge Only When Recording (Visual Component)

{
  recordingState === 'active' && (
    <div className="absolute -top-2 -right-2 animate-slide-in-from-top-2">
      <div
        className={`neumorphic-mode-badge ${
          currentRecordingMode === 'manual' ? 'mode-manual' : 'mode-auto'
        }`}
      >
        {currentRecordingMode === 'manual' ? 'Manual' : 'Auto'}
      </div>
    </div>
  );
}

That’s it. No new state management. No architectural changes. No disruption to existing workflows.

The Design Integration Challenge

The technical implementation was straightforward. The design challenge was harder: how do you add visual elements to an interface users describe as “perfect”?

Our solution was neumorphic mode badges that match the existing design system exactly:

  • Auto Mode: Green badge with emerald accent (--excitement-emerald)
  • Manual Mode: Blue badge with focus blue (--focus-blue)
  • Typography: Inter font, 10px, 600 weight, uppercase
  • Shadows: Same neumorphic shadow system (--neu-shadow-raised)
  • Positioning: Absolute positioning that doesn’t shift existing elements

The badges appear only during active recording and disappear with the recording state. They’re additive, not disruptive.

What Went Wrong (And Right)

The TypeScript Saga: Our IPC backward compatibility broke TypeScript compilation. The fix required proper type assertions for the legacy string format:

// Handle both old string format and new object format
if (typeof data === 'string') {
  callback(data as 'idle' | 'recording' | 'transcribing');
} else {
  callback(data.status, data.mode);
}

The Linting Marathon: Every time we thought we were done, Prettier wanted different formatting. Three rounds of npm run checks:fix later, we learned to run linting before declaring victory.

What Went Right: The surgical approach meant debugging was contained. When something broke, we knew exactly which 30 lines to examine. No cascading failures. No mysterious state interactions.

The Business Reality of Surgical Features

Here’s what this approach gives you as a technical product manager:

User Trust Preservation: Users can’t hate what you didn’t break. The core experience remains untouched.

Fast Time-to-Value: 2 hours from concept to working feature vs. 20+ hours for comprehensive redesign.

Easy Rollback: If the feature doesn’t land well, removal is a 5-minute git revert. No database migrations, no user data concerns.

Iterative Improvement Path: Start with the minimum viable enhancement. Learn from user feedback. Iterate only if needed.

Development Velocity: Ship small improvements weekly instead of big features quarterly.

The Framework: When to Go Surgical

Use the surgical MVP approach when:

  • ✅ Users love the current experience - Don’t fix what isn’t broken
  • ✅ The feature request is incremental - Enhancement, not transformation
  • ✅ Existing infrastructure can support it - Leverage what you’ve already built
  • ✅ Failure cost is low - Easy to remove if users don’t like it
  • ✅ Success doesn’t require perfection - 80% solution solves the real problem

Don’t use it when:

  • ❌ Core user workflow needs changing - Some problems require architectural solutions
  • ❌ Technical debt is blocking you - Sometimes you need to fix the foundation first
  • ❌ Users are asking for major capabilities - Don’t try to surgical your way to a different product

What This Means for Solo Builders

The surgical MVP philosophy is perfect for solo builders because it aligns with our core constraint: we can’t afford to break things.

Big companies can ship broken features and fix them in v2. They have customer success teams to handle frustrated users. They have QA departments to catch edge cases.

We don’t. When we break something users love, we’re on our own to fix it. And there’s no guarantee those users stick around while we figure it out.

The surgical approach lets us improve products without risking the trust we’ve earned. It’s product management for people who can’t afford to be wrong.

And honestly? After 25 years in tech, I’m convinced most features should start surgical anyway. Build the minimum that works. Learn from real usage. Then decide if more complexity is actually needed.

Most of the time, it isn’t.

Building VoiceCatcher has been a masterclass in restraint. Sometimes the best product decision is knowing what not to build. Want to follow along with our development journey? Check out our other posts on surgical product development and building features users actually want.