3 weeks after I posted CapyBro here: what Product Hunt, the Microsoft Store, and a stack of blog posts actually did
Three weeks ago I posted here about CapyBro — an open-source, hotkey-driven AI text rewriter for Windows. A few of you gave sharp feedback (including a solid pressure-test on the name). I said I'd run the launch and report back, so here's the honest version.
What I actually shipped since then
- Launched on Product Hunt.
- Got CapyBro certified and listed on the Microsoft Store — including a native ARM64 build — for $0, with no paid code-signing certificate.
- Wrote three technical deep-dives: the Win32 paste-back rabbit hole (dev.to), a Windows-hotkey utility guide, and a "ship a .NET app to the Store for $0" guide (Hashnode).
- Listed on AlternativeTo and a handful of indie/AI directories.
What worked better than I expected
- The Microsoft Store was the highest-leverage, lowest-cost move. The MSIX route means Microsoft signs the package — no ~€200/yr EV certificate, no SmartScreen "unknown publisher" wall, and you inherit a trusted install channel plus automatic Bing/Google indexing. For a solo Windows dev this is the single biggest unlock, and almost nobody talks about it.
- Open source did more for trust than any feature list. "MIT core + a local Ollama mode so your text never leaves the machine" landed in conversations far better than bullets about rewrite/translate/paraphrase.
- Technical deep-dives out-performed launch posts. A post explaining how the Win32 focus/paste-back actually works got real engagement from .NET devs. Generic "we launched!" posts got crickets.
What didn't work / surprised me
- "Broad beats niche" is a lie. My widest-reach posts converted worst. The narrow, specific, technical ones brought the people who actually installed it. (Ironically, that's exactly the advice I keep leaving in other people's threads here.)
- A launch isn't an event, it's a slog. "Launch day" moved almost nothing on its own. The compounding came from a back catalog of content that's indexable later.
- Naming debates are a trap. I got thoughtful pushback that "CapyBro" sounds too playful for a serious utility. I kept it — the friendliness is the positioning (indie, open-source, anti-subscription, not enterprise SaaS). One thoughtful comment is noise; I'll act only if 5+ people independently say the same thing.
The honest scoreboard
Early and modest. This isn't a "$10k MRR in 30 days" post — CapyBro is a $19 one-time tool, on purpose, so there's no MRR to flex. The real win so far is distribution surface: a Store listing, indexable comparison/technical content, and a few channels that keep paying out slowly.
What's next
- More comparison and use-case content — the long-tail search intent is the actual engine.
- Weighing whether a Linux/Avalonia port is worth it (one reviewer told me "yes, if Linux," which is filed away).
If you're a solo dev sitting on a finished Windows app and dreading a €200 certificate: look at the MSIX → Microsoft Store route before you spend a cent. Happy to share the exact gotchas.
— Roman
Trending on Indie Hackers
One of my first 10 users became a daily user. The other 9 didn't.
the deep-dives-outperform-launches finding is one of the most under-published lessons in indie distribution. mihir is right above that 'teaching the hard version' converts because the reader is feeling the pain while reading. quick add on the open-source part, OS positioning works less as a 'we share values' signal and more as 'this person will still be around in 2 years' signal. closed-source single-dev tools die when the dev gets busy; OS tools have the audit-trail and the community-fork insurance baked in. that perceived continuity is what unlocks the trust install.
totally — "still be around in 2 years" is a sharper frame than the values one, i'm keeping that.
for something like CapyBro it actually shows up as a slightly different objection. it's a tray app that can read whatever text you select, so the first thing people think isn't "will this be maintained," it's "is this quietly sending my text somewhere." closed-source can claim no telemetry; open-source lets them verify it in about 30 seconds. that's a whole segment — the privacy-burned ones — that a closed single-dev tool basically can't convert no matter how good it is.
and your insurance framing is exactly right, i'd just push on it a bit: almost nobody actually forks. the value isn't in using the option, it's in knowing it's there. it's insurance you never claim — but "i could fork it" is what kills the lock-in fear at install time. the optionality does the converting, not the act.
the part that surprised me is the audit-trail also disciplines the dev. every commit is public, so "i'll just add a little telemetry later" isn't really a door that's open to me anymore, even if i got tempted. open-sourcing turned out to be a commitment device i set for myself.
Nice to see the report-back, and the Microsoft Store plus ARM64 build for $0 is a great result. I looked at the site from the technical side, and the good news is it's in solid shape. Performance is 97, SEO is a clean 100, and accessibility and best practices are both 96. For someone whose growth plan is content and long-tail search, having the base this tidy is exactly what you want, because the pages you publish will load fast and rank without fighting the setup.
Two small things stood out, both tied to that content plan.
First, readability. The dark theme looks good, but some of the secondary text is a little light. The muted grey body text comes out around 2.6 contrast where 4.5 is the comfortable line, at about 12px. It's not painful, but since your whole engine is people actually reading your articles, it's worth making that text easy on every set of eyes, not just the folks with perfect vision. Lifting that muted grey a few steps, and maybe nudging the smallest sizes up, would do it. Cheap change, and it helps exactly the readers you're working to attract.
Second, one real bug. Your homepage throws a React hydration error (#418) in the console. That's when the HTML rendered on the server doesn't quite match what React draws when the page loads. On Next.js it's usually something small, like a date or a browser-only value rendered during the server pass. It often causes a brief flicker or re-render. Mostly a polish thing, but worth tracking down since you're putting real weight on this page.
Other than that it's fast, clean, and well built.
Appreciate an actual audit — most "feedback" is vibes, this is checkable. Right on both. The muted grey is a single token I can lift a few steps without touching the rest of the palette, and nudging the smallest sizes up is basically free — on it. The #418 is the interesting one: almost certainly a server/client mismatch from a value that's only stable client-side (relative-time/locale is my first suspect). I'd rather track that down than paper over it with suppressHydrationWarning. Thanks for digging in.
You're hunting it exactly right. Relative-time and locale are the classic #418 causes: a "2 hours ago" or a localised date that the server and client format differently. Resisting suppressHydrationWarning is the right instinct too, that only hides the mismatch. Render those timestamps from a fixed locale and timezone on first paint and it usually goes quiet. Nice work turning the contrast token around so fast as well.
The Microsoft Store finding is genuinely surprising and useful most indie devs completely ignore it because it feels like a graveyard. The fact that it outperformed Product Hunt on retention makes sense though. Store discovery has longer tail intent than a launch spike. Would be curious what your day 7 retention looked like from each channel. That number probably tells the real story more than install counts.
Honest answer: I can't cleanly measure day-7 retention because the app ships with no telemetry on purpose (local-first is half the pitch). So I read proxies — Store "active devices", repeat release downloads, and support emails that reference daily use — and by those, Store installs stick harder than the PH spike, which decayed in ~48h. The irony is that the privacy stance which helps adoption also blinds me to the exact number you're asking for. How are you measuring it on your side?
The "broad beats niche is a lie" point is the one that keeps coming up and nobody believes it until they see it firsthand.
Few weeks into the same thing with MyRundown[dot]io. The posts targeting a specific search intent did way more than anything I wrote about the product itself. One post about clearing a Pocket backlog has more impressions than my actual launch content.
The blog as back catalog framing is right. Doesn't feel like progress when you're writing it but it compounds in a way launch posts don't.
MSIX tip is genuinely useful, bookmarking that for if I ever touch Windows distribution.
"One post about clearing a Pocket backlog out-impressions the launch content" is the whole thesis in one line. The launch post is a flare; the use-case post is a streetlight that stays on. The MSIX tip's there for whenever you touch Windows — happy to share the exact makeappx/StartupTask gotchas if you get to it. What's MyRundown's wedge?
Wedge is the delivery model! Every "read later" app makes you go back to it. My Rundown sends a summarized digest to your inbox instead. You already open email every day, you don't always remember to open another app! Small shift but it's the one that actually changes the habit.
"Broad beats niche is a lie" is going to help a lot of people who read this post, including people who probably left that advice in someone else's thread.
The mechanism behind it: specific content self-selects. Someone clicking on a post about "the Win32 focus/paste-back rabbit hole" is already halfway to your target user before they read a single word. Generic launch posts reach a wider audience with lower intent — the install rate is terrible because most people who see it don't have the problem.
The naming insight is also worth keeping: "I'll act only if 5+ people independently say the same thing" is a solid heuristic. One thoughtful comment is noise. Convergent feedback from unrelated people who all hit the same friction without prompting — that's signal worth taking seriously.
The MSIX / Microsoft Store zero-cost signing path is genuinely underreported. The mental model most Windows devs have is still "pay for an EV cert or deal with SmartScreen popups." If the Linux/Avalonia port comes together, the trust problem flips entirely because the open source community expects to build from source anyway.
Useful update. The "indexable content back catalog" framing for launch is the correct way to think about this at your stage.
"Specific content self-selects" is better than how I put it — the reader qualifies themselves before reading a word, so install rate is basically just intent rate. And the Avalonia point is exactly why the Linux port keeps nagging at me: on Windows "open source" is a trust signal, but on Linux it's table stakes (build-from-source is the expected path), so the whole positioning flips from "nice, it's MIT" to "of course it's MIT." Still weighing whether that audience is worth the port cost. Thanks for the thorough read.
The install rate = intent rate reframe is precise and actually makes the MS Store numbers look more useful as a signal — low volume, high qualification. On the Linux question: the port cost isn't just engineering, it's also support surface. Linux users who build from source are generally low-friction support-wise, but they'll find every edge case. Worth scoping what 'port' means before committing — a proper Avalonia port is one thing, but an AppImage might let you test Linux appetite with 20% of the effort.
The MS Store/MSIX path is an underrated distribution play. We saw the same thing with DictaFlow on Windows — organic discovery inside the Store plus the trust bump from a verified listing beats a random .exe download every time. Interesting that you're on the text-output side with CapyBro and I'm on the input side with DictaFlow: hold-to-talk dictation that types into any app via a hotkey. Two ends of the same hotkey-text problem. How are you approaching the comparison/alternative content side? That's been the slow-burn winner for us too.
Text-out and voice-in as two ends of the same hotkey-text problem is a clean way to put it. On comparison content: I'm going narrow and intent-led — "vs Grammarly", "vs the ChatGPT-tab workflow", and per-persona use-case pages (devs/students/writers) rather than broad "best AI writing tools" listicles. The specific-intent pages convert; the broad ones bring traffic that bounces. For DictaFlow I'd guess "X dictation alternative" + "hands-free coding/writing" intents are your slow-burn. What's converted best for you so far?
Interesting can you share this story on my forum : ) https://dev.us.kg/
Thanks — glad it was a useful read! I'm keeping the write-ups on my own blog + IH/dev.to so the discussion stays in one place, but appreciate you reaching out.
One thing I'd be careful with:
The interesting question may not be which channels worked.
It may be what conclusion deserves confidence because they worked.
Those sound similar, but they can lead to very different decisions about positioning, expansion, and where future effort gets invested.
I'd be especially careful because several of the signals you described can look validating while pointing in different directions underneath.
Good push, and you're right that that's the trap. The one conclusion I'd actually stake something on is narrow and almost mechanical: the Microsoft Store / MSIX path is a high-leverage, near-zero-cost distribution channel for a Windows app — that's a fact about the channel, not about CapyBro's product-market fit. Everything softer (which audience, which positioning) I'm treating as a weak signal, not validation — too early, too few data points to bet direction on. What I'm watching for is the same conclusion showing up from independent channels before I act on it. Which of the signals looked most "validating-but-misleading" to you?
Honestly, I think the first-line test is stronger than the name debate anyway.
I've seen products survive imperfect names for years. It's much harder when people remember the product but walk away with the wrong mental model of what it actually is.
That's the part that would make me nervous before a bigger launch.
YOUR EMAIL
If it's easier, feel free to drop me a note at [[email protected]] and I'll send over the longer version there.
the microsoft store point is the one nobody talks about and it's real, kinda wild it isn't common knowledge yet. the smartscreen 'unknown publisher' wall kills more windows installs than people think, i've watched conversion fall off a cliff right at that screen. msix sidesteps the whole thing. curious whether the store drove installs on its own for you though, or if it's mostly the trust and indexing and the installs still came from PH and the blog posts.
This breakdown is useful because it separates visibility from buyer intent. I’m tracking the same split for Kinetic Override: broad launch surfaces help legitimacy, but Android utility/comparison surfaces and exact “no-root auto clicker / macro recorder” searches are the real signal.
Great read!
The point about "a launch isn't an event, it's a slog" is something I wish I read before I launched. I spent so much energy on launch day expecting a spike — got almost nothing. The slow burn from genuine community engagement ended up being what actually moved the needle.
Your observation about narrow, specific content outperforming broad launch posts matches exactly what I experienced. A genuine reply to one person's specific question brought more users than any "I launched!" post I wrote.
The Microsoft Store tip is gold for Windows devs — that MSIX route is something most solo devs don't know about. Thanks for sharing the honest numbers too, refreshing to see a post that isn't just a vanity metrics flex.
“Desperate, not curious” is the key point here.
Broad posts get attention, but replacement/alternative searches usually bring people who already know the pain and want a fix now.
The "technical deep-dives outperformed launch posts" pattern makes sense when you think about who reads each one. A launch post attracts people who browse IH/PH for entertainment. A post about Win32 focus/paste-back mechanics attracts someone actively building a keyboard-driven workflow who hits that exact wall. They're already pre-qualified by the time they reach your download link.
It's the same reason "how I built X" posts convert better than "X is now live" posts for dev tools. Teaching the hard version of what your product automates is the highest-conversion content you can write, because the reader is feeling the pain while reading.
The Microsoft Store MSIX trick is a genuine find. SmartScreen is the silent killer for indie Windows tools, most users just close the tab when they see "unknown publisher."
“A launch isn't an event, it's a slog.“ If anybody researching how to launch came away with only that nugget, they would be ahead of the game. It’s definitely a slog, and if you aren’t ready for that, launch day can be depressing. Just have to lean into it and drive. Try different things and see what works best.
The Microsoft Store finding is the most underrated thing here. Everyone chases Product Hunt for the spike but ignores the channels with actual long tail intent. A user who finds you by searching a specific problem in the Store is already 10x more qualified than someone who upvoted you on a launch day.
The specificity point about content is the same lesson. Narrow audiences self-select. What was the most specific piece you wrote and did it outperform everything else by a lot?