5 things I learned from building and releasing Hounty
Source: Dev.to
First of all, I can’t believe Hounty is actually out!
It’s been so long since I started a small project that turned into a year‑long crusade, and I couldn’t be prouder of crossing this threshold.
TL;DR
You can download Hounty for free on the App Store.
The app is written in Flutter, and the backend uses Serverless Go + Serverless PostgreSQL.
Looking back, I wouldn’t change many things—the lessons had to be learned—but I wish I’d known a few things sooner.
1. Build in Public
The idea is great for building trust and relationships, but it only works if:
- You are building a tool aimed at developers.
- You have something for them to try.
The same applies to building a community on social networks before the app is ready. When I submitted the new shiny Freemium version for release, I made the previous version free and shared a “Coming soon” video with an app preview on TikTok:
Five hundred downloads are amazing! Except those users were frustrated when they didn’t find the new AI‑cleaning planner and were met with a completely different design…
My point: advertise only what is ready.
2. Deploy Small Changes
I rewrote the UI and backend several times, and each iteration took weeks—until I hit exhaustion or painted myself into a corner. It only started to work when I applied what I preach: refactor as you go.
Example: I was working on a sync feature and wanted to change the logic from log‑based storage (all events stored in one table and replayed on the device) to entity‑based storage (each entity stored in its own table with its own versioning).
At first I tried rebuilding everything at once, which was frustrating and nearly made me abandon the project. Then I switched to moving small pieces:
- Moved the files of one entity into a separate folder, tested, committed, deployed.
- Wrote an abstraction for the command pattern, refactored one “submodule”.
- Refactored the rest one‑by‑one.
- Changed the storage one‑by‑one.
Apparently, this approach works not only for teams—who would’ve thought?!
3. Play Store Requires 2 Weeks and 12 Beta Testers
This was new to me. My old Play Store publishing account was no longer usable (perhaps because it was created in Russia or due to a mistake), so I had to create a new one. I discovered that I needed 12 beta testers to test the app for 2 weeks before I could release it.
My friends and family are on Apple devices, so the process was slower than expected.
There’s a “testercommunity” app and several Reddit communities where people support each other, so it’s not a deal‑breaker. I chose to focus on the App Store for the initial launch.
4. App Store Subscriptions Are a Hassle
Releasing a one‑time‑pay version was easy—it got approved in two days. The free version with subscriptions took almost 2 weeks of back‑and‑forth.
- What went wrong?
- I didn’t add the subscriptions to the release, so the app went out with a beautiful paywall but no working subscriptions.
Tips:
- Ensure all subscription locales and required fields are filled and that the status is “Ready for review” before submitting a new version.
- Add the subscriptions to the version before you submit it for review. If you can’t find where to do this, the subscriptions aren’t ready.
- Include a dedicated “Restore purchases” button even for subscriptions, even if you store them on a user account.
- Add a link to your Terms of Service in the description.
- After release, subscriptions may lag and not appear on the App Store or in your app for 8–24 hours. Joy!
5. Tech Stack for Solo Developers
Working alone after hours with limited time makes LLMs a must, but they need a bit of hand‑holding. The choice of language influences how much assistance you’ll need.
- Anything web‑related that looks like React has been a breeze.
- Flutter was okay‑ish after I set up the scaffold, though I’m still hesitant to refactor most of it.
- I managed to make the backend work with Go, but if I did it again I’d choose Rust. I didn’t like the Rust compiler barking at me, but I love its strictness—keeps Sonnet and Opus in check. Plus, Rust has great documentation and a “one way of doing things” philosophy, which makes LLM predictions more reliable.
So Was It Worth It?
I don’t know what comes next yet—aside from a possible Rust rewrite, of course. It’s time to send Hounty into the world, look at the data, and iterate. It wasn’t easy; I’m not bragging about my MRR yet, but it’s been a fun ride.
I built something I’m proud of, users are downloading it, and my kids are showing me their perfect “before and after” clean‑ups. Yes, it was absolutely worth it!
Want to See My Clean Pics?
Here’s the cleaned‑up markdown for the image reference:
[Image: mykcsp7vnlpvjw70m383]