Shipping Two Desktop Apps in Parallel as a Side Project

The Setup

I work full-time as a Senior Lead Developer at Planetary, a digital agency in New York. Our clients include Din Tai Fung, The Well, Burlington, Dow Jones. The work is demanding -- production launches, design system maintenance, client calls, code reviews. It fills the standard eight hours and sometimes more.

Outside of that, I run Helsky Labs, my indie hacker umbrella brand. In the last few months, I shipped two desktop applications simultaneously: DropVox, a native Swift/SwiftUI macOS menu bar app for transcribing voice messages using WhisperKit, and Falavra, an Electron + React + TypeScript app for transcribing YouTube videos using sherpa-onnx.

Two desktop apps. Two different tech stacks. Two different distribution strategies. While working full-time. This post is about how that actually worked in practice -- the schedule, the decisions that made it possible, the trade-offs I accepted, and the honest assessment of whether I would recommend this approach.

Why Two at Once

The obvious question: why not finish one, then start the other? I had good reasons, though I acknowledge they only make sense in retrospect.

DropVox and Falavra solve different problems for different users. DropVox is for people who receive voice messages and want instant transcription -- it lives in the macOS menu bar and transcribes audio files dropped onto it. Falavra is for people who watch YouTube and want searchable transcripts -- it is a full windowed app with a library, search, and export features. The user overlap is minimal.

More importantly, the projects share a conceptual core. Both deal with Whisper AI models, audio processing pipelines, local-first architecture, and macOS distribution. The knowledge transfers bidirectionally. When I solved binary bundling in Falavra (packaging yt-dlp and ffmpeg inside an Electron app), the solution informed how I thought about model distribution in DropVox. When I implemented WhisperKit's streaming API in DropVox, it clarified the architecture I wanted for sherpa-onnx integration in Falavra.

Context switching between the two projects is, counterintuitively, a feature. When I am stuck on a problem in one app, switching to the other gives my subconscious time to work on it. I come back to the first project with fresh eyes and, frequently, a solution. This does not work if the projects are too similar -- you just carry the same frustration between them. It works because DropVox is Swift and Falavra is TypeScript. The mental context is different enough to provide genuine rest.

The Schedule

Let me be specific about the hours, because vague claims about "working on side projects" are useless without context.

Weekday evenings: 1-2 hours. After work ends, after dinner, after my wife and I have had actual human conversation, I sit down around 9pm. I work until 10:30 or 11. These sessions are focused: I pick one task before sitting down, and I do that task. No browsing GitHub issues. No redesigning the landing page. One task.

Weekend mornings: 3-4 hours. Saturday and Sunday mornings, I start at 7am. By 10 or 11am, the deep work is done. Afternoons are for life -- groceries, exercise, friends, rest. I do not touch code on weekend afternoons. That boundary is non-negotiable.

Total: roughly 10-15 hours per week across both projects. Some weeks it is closer to 8 when agency work is intense. Some weeks it is closer to 18 when I am approaching a release. The average settles around 12.

The critical detail: I never work all day on side projects. Not on weekends, not on holidays. Sustainable pace is the constraint that makes everything else work. If I sprinted -- 40 hours a week on side projects on top of 40 hours of agency work -- I could ship faster. For about three weeks. Then I would burn out, resent the projects, and abandon them. I have seen this pattern in other indie hackers, and I have felt it in myself during earlier attempts.

What Made It Possible

Claude Code as a Force Multiplier

I need to be direct about this: shipping two desktop apps in parallel would not have been feasible without AI assistance. Not because AI writes my code -- it does not, not in the way people imagine. I make every architectural decision. I design every system. I debug every issue. But Claude Code executes the mechanical parts faster than I can type them.

When I decide that Falavra needs a SQLite FTS5 search feature, I do not spend 40 minutes writing the migration, the query functions, the IPC handlers, the Zustand store methods, and the React components. I describe the architecture, provide the constraints, and Claude Code generates the implementation. I review it, adjust it, and commit it. What would take a full evening takes an hour.

This is not a productivity hack. It is a fundamental change in what one person can ship per hour of focused work. The bottleneck shifts from typing speed and API memorization to architectural judgment and product taste -- which is where I want to be spending my time anyway.

CLAUDE.md as Persistent Context

Each project has a detailed CLAUDE.md file that describes the tech stack, the architecture, the conventions, the current state of development. When I sit down for an evening session, I do not need to spend 20 minutes re-establishing context. The CLAUDE.md is the context. It includes what has been built, what the current priorities are, what patterns to follow, what pitfalls to avoid.

This is a form of documentation that serves double duty. It keeps Claude Code aligned with my architecture, and it keeps me aligned with my own decisions from last week. At 11pm on a Tuesday, I do not always remember why I chose sequential job processing over parallel. The CLAUDE.md reminds me.

Atomic Commits

Every coding session produces small, focused commits. A single session might produce three to five commits: "feat: add FTS5 virtual table migration," "feat: implement search query in main process," "feat: add search UI to library view." Each commit is self-contained and buildable.

This matters for parallel projects because it makes context switching cheap. When I switch from Falavra to DropVox, I do not need to remember where I left off. I look at the git log, see the last few commits, and know exactly what state the project is in. If I had accumulated large, uncommitted changesets, switching would require holding partial state in my head across days. That does not work.

The Helsky Labs Dashboard

I built a centralized dashboard (a separate project, also under Helsky Labs) that shows all products on one screen. Traffic, revenue, active visitors, deployment status. When I sit down for a coding session, I spend two minutes looking at the dashboard to decide which project needs attention. If DropVox had a traffic spike from a Reddit mention, I focus on DropVox. If Falavra has been flat for a week, I focus on Falavra.

Data-driven prioritization sounds corporate, but for a solo operator with limited hours, it prevents the most dangerous pattern: working on whichever project feels most fun instead of whichever project needs the most attention.

Shared Infrastructure

Both apps use the same Umami instance for analytics. Both landing pages follow the same design system patterns. Both use the same release playbook for macOS notarization. Both are tracked in the same dashboard. The shared infrastructure means I am not maintaining two completely separate ecosystems. Bug fixes to the analytics integration help both products. Improvements to the release playbook apply to both.

The Trade-offs

I want to be honest about what I gave up.

Neither app has every feature on the roadmap. DropVox does not have batch processing yet. Falavra does not have subtitle export. The roadmaps are long, and the shipping rate is steady but not fast. Features get prioritized ruthlessly, and "nice to have" features stay on the list indefinitely.

Documentation is minimal. Beyond the CLAUDE.md files (which are internal development context, not user documentation), there is very little written documentation for either project. The code is the documentation. This is fine for solo development but would be a problem if I ever onboarded a contributor.

No automated tests in the early versions. This is the trade-off I am least comfortable admitting. Both apps shipped their initial versions without automated test suites. The reasoning was pragmatic: with limited hours, I chose to ship features over writing tests. The risk is real -- regressions happen, and I catch them manually. As both apps stabilize, I am adding tests incrementally. But the early versions were tested by hand, and I should be transparent about that.

Marketing is almost non-existent. I have no dedicated marketing time. Blog posts like this one serve double duty as content marketing, but there is no SEO strategy, no social media calendar, no ad spend. The products grow through word of mouth and organic search. This limits growth velocity but eliminates a time commitment I cannot afford.

Shared Learnings Between Projects

The most valuable aspect of running both projects is the knowledge transfer.

Whisper integration patterns. DropVox uses WhisperKit (Apple's optimized Whisper implementation for Core ML). Falavra uses sherpa-onnx (a cross-platform ONNX runtime). The APIs are completely different, but the patterns are the same: model management, progress reporting, memory constraints, accuracy vs. speed trade-offs. Solving a problem in one runtime illuminates the same problem in the other.

macOS code signing and notarization. Both apps need to be signed and notarized for distribution outside the App Store. The process is identical regardless of whether the app is native Swift or Electron. I built the notarization workflow once and use it for both.

Local-first architecture principles. Both apps process data locally. No cloud APIs, no accounts, no data leaving the user's machine. The design principles -- offline capability, local storage, bundled dependencies -- are the same. Decisions I make about data storage in Falavra (SQLite + FTS5) inform decisions in DropVox (Core Data with Spotlight integration).

Pipeline orchestration. Falavra's pipeline (download, convert, transcribe) and DropVox's pipeline (receive audio, detect language, transcribe, copy to clipboard) are structurally identical. Sequential stages, progress mapping, error isolation. The pattern is reusable across both codebases, even though the implementations share zero code.

Do not run two projects in parallel if neither has been validated. I started Falavra after DropVox had already found its initial users. I had evidence that local Whisper transcription was something people wanted. Falavra was a bet on the same thesis applied to a different use case. If both projects were pure speculation, running them in parallel would be doubling down on risk.

Do not maintain two codebases in the same language if the products could share code. DropVox is Swift and Falavra is TypeScript. There is no shared code between them, and that is fine because the stacks are fundamentally different. If both were Electron apps, I would have built a shared library and shipped them as a monorepo. Duplicating code across two projects in the same language is a maintenance burden that compounds over time.

Do not sacrifice sleep. I said it before, but it bears repeating. The hours I listed -- 10 to 15 per week -- come from evenings and mornings, not from nights. I sleep seven to eight hours. I do not code at 2am. The romanticized narrative of the sleep-deprived founder shipping features at midnight is a path to burnout, bad code, and failed projects. Sustainable pace is not a nice-to-have. It is the strategy.

The Portfolio Effect

Running two products under one brand produces a compound effect that is hard to see from the inside.

Two products is more credible than one. When someone visits the Helsky Labs site and sees DropVox and Falavra, they see a pattern of shipping, not a one-off experiment. Each product serves as social proof for the other.

The dashboard provides portfolio-level insights that single-product metrics cannot. I can compare growth rates across products, identify which marketing channels (blog posts, Reddit, Product Hunt) drive traffic to which products, and allocate my limited hours accordingly.

Each product cross-promotes the other. DropVox users who need YouTube transcription discover Falavra. Falavra users who want quick voice message transcription discover DropVox. The products are complements, not competitors.

Honest Reflection

This pace is only sustainable because I genuinely enjoy building these things. The evenings and weekend mornings do not feel like a second job. They feel like the most creative part of my week. The agency work is rewarding in its own way -- big clients, real users, professional challenges -- but the indie projects are where I have complete creative control. I choose the stack, the architecture, the features, the timeline.

The moment this stops being enjoyable -- the moment I sit down at 9pm and feel dread instead of curiosity -- the two-project strategy fails. I have seen indie hackers push through that feeling and produce worse and worse work. The output of a motivated evening hour is worth more than three hours of grudging obligation.

Eleven years into this career, I have learned that my best work comes from genuine interest, not discipline. Discipline gets you to the desk. Interest keeps you there. Running two side projects in parallel works for me because both projects hold my interest. That is not a strategy anyone else can copy directly -- but the underlying principle is universal: build things that make you want to sit down and work on them.

If you are shipping side projects alongside full-time work, or thinking about starting, I would love to hear your approach. Find me on LinkedIn or see what I am building at helrabelo.dev.