From Zero to Two Shipped Apps: My First Month as an Indie Hacker
I have been writing code professionally for eleven years. In that time I have shipped dozens of websites for clients at Planetary -- Din Tai Fung, The Well, Burlington, Dow Jones. Polished, tested, approved by three rounds of stakeholders. Beautiful work that lives on someone else's domain under someone else's brand.
In all of those eleven years, I shipped exactly zero products of my own.
Not for lack of trying. I have a graveyard of side projects. A habit tracker that got to 80% and stalled. A recipe app that I built the backend for and never touched the frontend. A personal finance dashboard that exists as a Figma file and nothing else. If unfinished side projects were a currency, I would be wealthy.
Something changed in January 2026. In the span of about four weeks, I shipped two real products -- DropVox and TokenCentric -- under a brand I created called Helsky Labs. Not prototypes. Not demos. Signed, notarized, downloadable applications that people can actually use.
This is what I learned.
Why Now, After Eleven Years
Two things changed simultaneously: tools and mindset.
The tools part is straightforward. Claude Code became my force multiplier. Not in the "AI writes my app" sense -- I still architect, I still make every decision, I still debug at 11 PM. But the velocity is different. Things that used to take me a full weekend of research and implementation now take an evening. The friction between having an idea and having working code dropped dramatically.
The mindset part was harder. Agency work trained me to polish everything. When a client is paying six figures for a website, every pixel matters. Every interaction is reviewed. Every edge case is handled. That instinct is valuable in client work and absolutely lethal for side projects.
The breakthrough was simple, almost embarrassing to say out loud: I gave myself permission to ship imperfect software. Not broken software. Not bad software. But software that does one thing well and doesn't do ten other things yet. Software where the settings screen is a bit plain and the onboarding could be smoother. Software that is good enough to be useful.
The decision to build two products in parallel under one brand was deliberate. I wanted Helsky Labs to feel like a studio, not a one-off. Each product is small on its own, but together they start to build something.
DropVox: Because My Wife Sends Voice Notes
The origin story is almost comically domestic. My wife sends WhatsApp voice messages. Long ones. Five minutes of Portuguese while I am in a meeting, unable to put in earbuds, with no idea if she is telling me about her day or asking me to pick up the kids.
WhatsApp has no transcription feature. The existing solutions all involve uploading your audio to someone's cloud, which means your private voice messages live on a server you don't control. That felt wrong.
So I built a thing. First as a Python prototype over a weekend -- a menu bar app using OpenAI's Whisper model that transcribed audio files locally. It worked. I used it every day. Then I rewrote the entire thing in native Swift because "works for me" is not a product.
Why Native Swift Instead of Electron
This was a deliberate bet. Electron would have been faster to build -- I am a JavaScript developer, after all. But DropVox is fundamentally an audio processing tool that lives in your menu bar all day. Performance and resource usage matter. Battery drain matters. Startup time matters.
Swift gave me access to WhisperKit, a framework by Argmax that runs Whisper models directly on Apple's Neural Engine. The same transcription that took 30 seconds in the Python prototype now completes in under 10 seconds on an M1 Mac. The models run on dedicated hardware that would otherwise sit idle. No cloud round trip, no API latency, no monthly bill.
The app ships with five model sizes -- Tiny at 75MB for quick-and-dirty transcription, up to Large at 3GB for maximum accuracy. For voice messages, the Base model hits the sweet spot. It handles both English and Portuguese accurately, which was non-negotiable for my household.
No Cloud, No Accounts, No Subscriptions
Every architectural decision reinforced the same principle: your audio stays on your machine.
There is no account creation. No cloud sync. No telemetry on what you transcribe. The AI model downloads once and runs locally forever. If you disconnect from the internet, DropVox keeps working.
Pricing reflects this. It costs $12.99 one time. Not $12.99 per month. Not $12.99 per year. One payment, you own it. There are no server costs per user, no API calls to bill for, no infrastructure scaling with usage. Charging a subscription for software that runs entirely on your hardware felt dishonest.
TokenCentric: The Developer Tool I Couldn't Find
While building DropVox, I ran headfirst into a different problem.
Every AI coding assistant has its own context file format. Claude Code reads CLAUDE.md. Cursor reads .cursorrules. GitHub Copilot reads .github/copilot-instructions.md. Windsurf reads .windsurfrules. They all do roughly the same thing -- give the AI project-specific instructions -- but they all use different files in different locations with different conventions.
Now multiply that across a dozen active projects. I had context files scattered everywhere. Some were 200 tokens. Some were 15,000. I had no idea which ones were bloated, which ones were stale, and whether that massive CLAUDE.md was actually hurting performance by eating into the response window.
I looked for a tool to manage this. Nothing existed. So I built one.
The Fragmentation Problem
This is a problem that only exists because the AI coding tools market is still young and fragmented. Five years from now, maybe there will be a standard. Today, every tool does its own thing, and developers who use more than one are stuck maintaining parallel instruction files.
TokenCentric solves this by being a single desktop app that discovers all context files across all your projects, lets you edit them with a proper Monaco editor, and most importantly, shows you the real token cost using each provider's official tokenizer. Not an approximation. Not "about 4 characters per token." The actual count, from Anthropic's tokenizer for Claude and OpenAI's tiktoken for GPT models.
Open Source and Free, On Purpose
I made TokenCentric free and open source under MIT. This was not generosity -- it was strategy.
TokenCentric solves a real problem, but it is a developer tool for a niche within a niche. The market for "people who use AI coding assistants and have enough projects that managing context files is painful" is real but not large enough to sustain a paid product. Making it free removes the barrier to adoption entirely. Making it open source builds trust with the exact audience that would use it.
The value to Helsky Labs is indirect: credibility, visibility, and proving I can ship. Every developer who uses TokenCentric sees the Helsky Labs name. Some of them might try DropVox. All of them know I build things that work.
Cross-Platform via Electron
Unlike DropVox, TokenCentric is an Electron app. The irony of choosing Electron for one product and rejecting it for another is not lost on me, but the reasoning is different. TokenCentric is a text editor at its core. Monaco -- the same editor engine that powers VS Code -- is a web technology. The bundle size penalty of Electron is irrelevant when you are already shipping a full code editor. And cross-platform support (macOS and Windows) matters for a developer tool in a way it does not for a macOS-specific voice transcription app.
What I Actually Learned
Shipping Beats Perfecting
This is the lesson everyone tells you and nobody believes until they experience it. My agency training made it worse. I spent eleven years in an environment where shipping means "reviewed by QA, approved by the client, tested across twelve browsers, and blessed by the project manager." That is the right process for client work. It is death for indie products.
The turning point for DropVox was realizing that version 1.0 does not need a Share Extension. It does not need speaker diarization. It does not need real-time microphone transcription. It needs to transcribe a voice message file and put the text on your clipboard. If it does that well, it is a product. Everything else is a future version.
I shipped DropVox without the features I was most excited about. That felt terrible and was absolutely the right decision.
Marketing Is Harder Than Building
This one caught me off guard, though it shouldn't have. I spent four weeks building two apps and roughly zero weeks telling anyone they exist.
The code is the easy part. I know how to write code. I have been doing it for over a decade. What I do not know how to do is get a macOS utility app in front of the people who need it. SEO takes months. Social media requires consistency I have not yet built. Product Hunt launches are a one-day spike that fades. Paid acquisition is expensive for a $12.99 product.
Nobody knows your app exists by default. The "build it and they will come" mentality is the most dangerous lie in indie hacking. I built two good products and the total number of people who know about them is roughly equal to my Twitter followers plus my wife.
This is the gap I am working on filling now. Blog posts like this one, content that demonstrates expertise, organic SEO around the problems these tools solve. It is slower than I would like, but it is honest work.
Building Two at Once Was Both Brilliant and Exhausting
The upside of parallel development: shared momentum. When I hit a wall on DropVox's code signing pipeline, I switched to TokenCentric's template system and made progress there. When Electron's notarization was breaking me, I went back to Swift and implemented the floating drop zone. Context switching kept me from getting stuck.
The downside: context switching is cognitively expensive. Swift and TypeScript are different languages with different paradigms. SwiftUI and React think about UI differently. The mental overhead of maintaining two mental models simultaneously is real.
If I had to do it over, I would still build both, but I would batch more aggressively. Two weeks on DropVox, two weeks on TokenCentric, rather than bouncing between them daily.
Going Public Is Emotionally Harder Than Expected
There is a specific vulnerability to shipping something with your name on it. Client work has a buffer -- if the website has issues, it is the agency's problem, shared across a team. When DropVox has a bug, that is my bug. My code. My decision. My name on the app.
The first time someone downloaded DropVox who was not me or my wife, I felt a knot in my stomach that I was not prepared for. What if it crashes? What if the transcription is garbage? What if they think it is amateurish?
That feeling has not gone away entirely. But it has become more manageable. Shipping the second product was easier than the first. I suspect the third will be easier still.
The Helsky Labs Vision
Helsky Labs is not one product. It is a portfolio of indie bets.
The model is deliberate: small products that solve real problems for specific audiences. Each one is a contained experiment. DropVox tests whether people will pay for local AI tools. TokenCentric tests whether developer tooling can build brand awareness. Future products will test other hypotheses.
The umbrella brand matters because no single product in this portfolio is big enough to build a reputation on its own. A $12.99 macOS utility and a free developer tool are not going to make anyone's "Top 10 Startups" list. But a studio that consistently ships useful, well-built software? That compounds over time.
The philosophy is simple: solve a problem you actually have, build the smallest thing that solves it, ship it, and move on to the next one. Some will find an audience. Some won't. The ones that don't teach you something. The ones that do fund the next experiment.
What's Next
The immediate priority is marketing. Both products are shipped and stable, but they need eyes. I am writing more, sharing the technical journey publicly, and building the kind of organic presence that takes time but compounds.
On the product side, DropVox has a roadmap that includes a Share Extension for system-level integration and potential App Store distribution. TokenCentric needs Windows and Linux builds and a context file linting system. There are more products in the pipeline that I am not ready to talk about yet.
If any of this resonates -- the graveyard of side projects, the agency developer wondering what it would be like to build your own thing, the fear of shipping something imperfect -- I get it. I was there for eleven years. The only thing that changed was deciding to stop waiting for the perfect moment and start shipping imperfect software.
It is working so far.
If you want to follow along: DropVox is the transcription app. TokenCentric is the context file manager. Both have deeper technical write-ups here on the blog -- Building DropVox, Shipping DropVox 1.0, and Building TokenCentric. You can also find me on GitHub.