TL;DR
In December 2022 I shipped a Witcher 3 mod as a side project. No marketing budget. No launch strategy. Three years later it has 93,614 unique downloads, 479,000 total views on Nexus Mods, 11 community translations, and is still running at version 4.4.1.
In this article I break down the three things that made it survive — and what every developer building side projects right now should do differently from day one.
▶️ Prefer video? Watch the full story on YouTube →
The project
If you've played The Witcher 3, you know the looting loop. You fight a monster. You walk to its body. You open the loot menu. You scroll through fifteen items. You pick what to take. You close the menu. You walk to the next monster and repeat — for forty hours.
It's one of the most tedious mechanics in an otherwise extraordinary game. Several AutoLoot mods existed when I started, but none of them had survived the Next-Gen Update that CD Projekt Red shipped in 2022. I took the best existing implementation, rewrote the core for Next-Gen compatibility, and rebuilt the entire configuration system so players could change everything from inside the game menu — no config files, no command line, nothing technical.
The first version went live on December 15, 2022.
Endorsements: 3,531
Unique Downloads: 93,614
Total Downloads: 176,949
Total Views: 479,192
Community Posts: 1,546
Translations: 11 languages
Current Version: 4.4.1
Last Updated: August 2024
Here's what made it last.
Lesson 1 — Solve the thing people are already searching for
The mod worked because it solved a pain that already existed and was already measurable. Every Witcher 3 player hit the same tedious loop. The problem needed no explanation. The value needed no selling. I just had to show the thing working.
Compare this to how most side projects start. We have an idea, we build something, and then we try to convince people they have a problem they weren't aware of. That's an extremely hard position to be in.
The mod had the opposite dynamic. People were already typing "witcher 3 autoloot mod" into a search bar. They already knew what they wanted. The project just had to be findable and better than what existed.
Those 479,000 total views came entirely from search — not from any promotion on my part. No social media campaign. No launch post. Just a real solution to a real pain point, discoverable at the exact moment someone needed it.
The question for your side project isn't "is this a cool idea?"
The question is: are people already frustrated enough to search for this?
If yes — you're in a much stronger position than you think.
Lesson 2 — Design for the community to own it
This one took me longer to understand. And it's the direct reason the mod is still alive in 2024 when I'm no longer the one maintaining it day-to-day.
Those 11 translations? People I have never spoken to, from countries I've never visited, translated the entire mod into their native language because they wanted their community to use it. I didn't ask them. I didn't hire them. The project was structured in a way that made contributing easy and meaningful.
Three things made that possible:
1. Public credit, always
Every contributor is listed by name on the mod page. This sounds small. It isn't. Public credit is the currency of open source communities. When people see their name associated with a project that tens of thousands use, they come back. They tell others. They defend the project when someone asks if it's still maintained.
2. A low contribution barrier
Translation files lived in a clearly named folder with a dead-simple structure. You didn't need to understand WitcherScript or the codebase to contribute a translation. The surface area for contribution was as small as I could make it.
3. An honest, visible changelog
Every update listed exactly what changed and why — not marketing language, actual technical notes:
v4.3.0 — Fixed exception when looting beehives with active bees
v4.2.1 — Added 3-second delay for Action Log notification after combat
v4.1.0 — Restored compatibility after TW3 patch 4.04
Specific. Real. Verifiable.
When your users can see that bugs get fixed and edge cases get handled, they trust the project. And when they trust it, they defend it in forums, recommend it to friends, and contribute back to it. Most of those 1,546 community posts aren't support tickets I had to answer — they're users helping other users.
That's the compound effect of designing for ownership. The community becomes your support layer.
Lesson 3 — Version like you mean it
The mod is on version 4.4.1. Not 1.0.1. Not a pile of undated commits. Four major evolution cycles, each minor number a documented change.
Semantic versioning — major.minor.patch — isn't just a convention for enterprise software. It's a communication contract with your users. When someone lands on your project page and sees v4.4.1, they know:
- This project has history
- It's been iterated on and tested
- The author takes it seriously enough to track changes
- There's a reasonable chance it still works
That signal builds trust before a single line of the README gets read.
But there's something deeper than version numbers here. It's about the cadence of care.
The last update was August 2024 — nearly two years after the first release. Each update wasn't arbitrary. It responded to something real: a CD Projekt Red patch breaking compatibility, a community-reported edge case, a configuration option users kept asking for. Updates were responses, not noise.
Most side projects die because the author loses interest and stops responding. Users feel it immediately. Forum posts go unanswered. Compatibility breaks stack up. Downloads drop. Eventually the project gets archived.
The antidote isn't endless motivation. It's a low, sustainable update cadence that signals to users that the project is alive. Even a single real patch every few months — documented, communicated — keeps the trust intact.
What I'd do differently today with AI
The biggest time cost in maintaining this mod wasn't writing the code. It was re-learning the codebase every time I returned to it after weeks away.
Witcher 3 uses WitcherScript — a custom language with its own quirks, patterns, and edge cases. Every time I came back to fix something, I spent significant time just re-orienting myself. What does this function do? Why was this architectural decision made? What are the things I must not touch?
This is exactly the problem I now solve at the root of every project with a CLAUDE.md briefing file — a persistent context document that tells my AI assistant everything it needs to know about the project before we start working:
# Project: AutoLoot All-in-One NG Update
## What this is
A Witcher 3 mod that automatically loots items during gameplay.
Uses WitcherScript (`.ws` files), compiled by the W3 Script Compiler.
## Architecture
- `/mods/AutoLoot/content/scripts/` — core loot logic
- `/mods/AutoLoot/content/scripts/ui/` — in-game config menu
- `lootConfig.ws` — DO NOT REFACTOR, breaks menu bindings
## Known gotchas
- Beehive loot triggers a unique exception — see `beehive_handler.ws`
- Always test after any CD Projekt patch — hooks change frequently
- Translation files in `/translations/` — one folder per language code
## What not to touch
- Menu binding IDs — hardcoded in game engine, not in our scripts
If I had this system in 2022, every return to the codebase would have taken minutes instead of hours. The AI would have been briefed. The context persistent. The cognitive overhead of maintenance — which is the real reason most side projects die — dramatically lower.
I cover the full setup of this system in my Obsidian + VS Code AI Second Brain video.
The three things that make software last
To bring it back together:
1. Solve a pain people are already searching for — let them find you, don't chase them.
2. Design for community ownership — credit publicly, lower the contribution barrier, keep the changelog honest.
3. Version with discipline — treat version numbers as a trust signal, not a formality. Sustainable cadence beats bursts of motivation.
None of these are unique to game modding. They apply to open source libraries, dev utilities, browser extensions, SaaS tools — anything you ship and want people to still be using three years from now.
If you're building something right now — even something small — treat it like it's going to be around in three years. Because if you do it right, it will be.
📺 Full video: I Shipped a Mod 93K People Downloaded — Here's What I Learned →
🎮 The mod: AutoLoot All-in-One NG Update on Nexus Mods →
🔔 3Gear channel — AI dev workflows + Next.js tutorials: youtube.com/@3Gear
💬 Building a side project right now? Drop what it is in the comments — I read all of them.
Top comments (0)