400+ downloads. Still fully free. Here's where things stand.
ATLOCK crossed 400 downloads recently — no ad spend, no PR, just word slowly spreading. That's genuinely more validation than I expected this early.
The honest state of things
I'm not running this as a business yet, not really. There's no pricing tier, no premium version, no paywall anywhere. Everything — System Lockdown, File Guard, the encrypted vault, Intruder Ops — is fully free, and that's not changing anytime soon.
Building solo means every hour spent on this is an hour not spent on something else, and right now this runs entirely on personal time — no funding, no team, no revenue engine behind it.
Why I'm not rushing to monetize
A few reasons:
- I'm 13, and setting up proper payment infrastructure (Stripe, Razorpay, etc.) needs an adult account holder — that's a "later, with my parents" conversation, not a "right now" one
- I'd rather earn trust first than ask for money before the product has proven itself
- A security tool asking for payment before it's established trust just feels backwards to me
The one thing that exists right now
The only way to support the project currently is a direct UPI tip on the website — genuinely optional, no features locked behind it, nothing changes if you don't. It's just there for anyone who wants to say "this was useful, here's something back."
Heads up: UPI only works for people banking in India, so this isn't something most of this community can actually use — that's just a limitation of where I'm starting from, not a choice to exclude anyone. If you're not in India, the best "support" is honestly just using the tool, starring the repo, or telling someone else about it.
What's next
Keep building, keep it free, keep listening to feedback. If a proper Pro tier or sponsorship model ever makes sense, it'll happen properly — with my parents involved in the business side of it, not as a rushed side feature.
🔗Website 👉 https://akhouri-anmol-kumar.github.io/Akhouri-systems/
🔗GitHub 👉 https://github.com/Akhouri-Anmol-Kumar
Curious how other solo/young builders here have thought about monetization timing — too early vs. too late is a real tension.
Top comments (3)
"400 downloads, no ad spend" is a much harder number to reach than most people posting revenue screenshots will admit, so congrats on that.
On the timing question — the thing I'd offer isn't about when, but about what to keep track of in the meantime. The trap I see most often in free-first security tools isn't monetizing too early or too late. It's that by the time the question becomes live, the builder has no idea which part of the product people actually stayed for. Four features shipped free means four hypotheses running at once. If a year from now you can say "File Guard is what retains people, Intruder Ops is what gets them to install," the decision is basically made for you. If you can't, you end up pricing the wrong thing.
That's cheap to start tracking now and expensive to reconstruct later, and it needs no payment infrastructure at all — just knowing which features get opened more than once.
The trust-first reasoning also holds on its own terms for this category. A security tool asking for money before anyone can verify it works is asking for two leaps at the same time.
This is a genuinely useful reframe — I hadn't thought about it as "four hypotheses running in parallel," but that's exactly what it is.
Here's the tension it surfaces for me though: ATLOCK v4's whole pitch is zero telemetry, nothing phones home. Which means the exact thing you're describing — knowing which feature gets opened more than once — is the one data point I've deliberately made impossible to collect, because collecting it Usually means shipping some kind of analytics call, and that's precisely the trust I spent v4 trying to build.
So the real problem isn't "track usage," it's "track usage without becoming the kind of app I removed, the tracking from in the first place."
The honest answer is probably local-only, opt-in usage logging — something that stays on the user's machine, that they can inspect or export themselves, rather than anything that leaves the device. That gets me the retention signal without reintroducing the exact depandency I just spent a release cycle removing.
Appreciate you pushing on this — I was thinking about the monetization question as a "when," and this reframe it as a "what am I even measuring against" question, which is a better place to start.
The local-only, inspectable log is the move, and I think "they can export it themselves" is doing more work than it looks - it flips usage data from something extracted to something offered, so you learn what gets opened twice without the user ever stopping being the owner of it. And yeah, "what am I measuring against" is the better first question. A growth number you can't tie back to a decision is mostly just anxiety with a chart.