← Build log

Simplicity Wins: The 30-Day Journey to Two Recording Modes

Pull up a chair, grab your favorite debugging beverage, and let me tell you a story about how we spent a month making something more complicated, only to realize the simplest solution was staring us in the face the whole time.

You know those moments in product development where you’re so deep in the weeds that you can’t see the forest for the trees? Yeah, this is one of those stories. Except the trees were environment variables, the forest was our codebase, and we were basically trying to build a treehouse while simultaneously arguing about what a tree actually is.

TLDR

What You’ll Gain:

  • How we simplified VoiceCatcher’s recording modes from a complex state machine to two simple hotkeys
  • Why moving logic to the right layer can eliminate entire classes of bugs
  • The exact implementation that solved our environment variable inheritance nightmare
  • A 30-minute fix that replaced 30 days of complexity

Bottom Line: Sometimes the best solution is to delete code, not write more of it.

The Problem: When Simple Features Become Complex

Remember when you were a kid and you’d make a simple task complicated just because you could? That’s essentially what we did with VoiceCatcher’s recording modes. We had two basic needs:

  1. Auto mode: Stop recording after silence (for quick commands)
  2. Manual mode: Keep recording until explicitly stopped (for long sessions)

Simple, right? Well, we managed to turn this into a three-ring circus of:

  • Environment variables that wouldn’t inherit properly
  • Config files that might or might not exist
  • IPC communication that felt like playing telephone with a bad connection
  • Mode-specific logic scattered across two languages

The Breakthrough: Sometimes Less is More

Here’s the “aha” moment that changed everything: We don’t need modes. We need timeouts.

Instead of building this complex system of modes, configurations, and state management, we realized we could achieve the exact same result with a single parameter: the silence timeout.

// The elegantly simple solution
function handleRecordingHotkey(isManual: boolean) {
  const timeout = isManual ? 1800 : settings.silenceTimeoutMs / 1000;

  // Same CLI call for both modes
  execFile('voicecatcher-capture', [
    '--silence-timeout',
    timeout.toString(),
    '--silence-threshold',
    settings.silenceThreshold.toString(),
    '--file',
    outputPath,
  ]);
}

That’s it. That’s the whole solution. Auto mode uses your configured timeout (typically 1.2 seconds), and manual mode sets it to 30 minutes. Same code path, same logic, just different numbers.

The Implementation: Honoring Separation of Concerns

Here’s where it gets interesting. By moving all mode-specific logic to the VoiceCatcher app layer, we:

  1. Simplified the Swift CLI to do one thing well
  2. Eliminated environment variable inheritance issues
  3. Reduced config file complexity
  4. Made testing straightforward
  5. Improved error handling

The interface is dead simple:

  • Ctrl+Backtick: Auto mode with user-configured timeout
  • Ctrl+Shift+Backtick: Manual mode with 30-minute timeout

What We Got Wrong (A Lot)

Oh boy, where do I start? In our quest to make this “robust”, we tried:

  1. Environment variables (they didn’t inherit properly)
  2. Config files (race conditions, anyone?)
  3. IPC communication (complexity we didn’t need)
  4. Mode-specific Swift logic (why was this even there?)

I have the git commits to prove it. Each one a monument to overthinking.

The Business Impact

This simplification means:

  • 70% less code to maintain
  • Zero config file dependencies
  • Eliminated 3 classes of bugs
  • Simplified testing surface
  • Better user experience

But the real win? When a new developer looks at this code, they’ll understand it immediately. No context-switching, no “well, actually” moments, just clean, obvious behavior.

What This Means for Solo Builders

Here’s the thing about being a solo technical founder: you don’t have someone to tap you on the shoulder and say “hey, maybe we’re overthinking this.” You have to develop that instinct yourself.

The next time you’re deep in a complex implementation, ask yourself:

  1. Could this be solved with a simple parameter?
  2. Am I building modes when I really just need values?
  3. Is this complexity serving the user or just satisfying my engineering ego?

Next Steps

If you’re building a similar feature, here’s your checklist:

  1. Map out the actual user needs (not the technical implementation)
  2. Look for parameters that could replace modes
  3. Push complexity up to the highest appropriate layer
  4. Delete unnecessary abstraction layers
  5. Test the simplest possible solution first

Remember: The code you don’t write is code you don’t have to maintain. Sometimes the best engineering is just knowing when to stop.

P.S. If you’re wondering why this post feels like a weight has been lifted, it’s because I literally just deleted 300 lines of unnecessary code. It feels good. You should try it sometime.