Building alone, designing together
I’m the only developer on Manu Idle. I write every line of code, design every screen, balance every progression curve. But the game isn’t mine alone — it’s been shaped by a Discord community of alpha testers who’ve been playing, breaking, and arguing about the game for months.
That relationship has changed how I think about game development.
What testing actually looks like
Alpha testing an idle game is different from testing most games. Testers don’t just play for an hour and report bugs — they live with the game. They run it for weeks, hitting edge cases that only appear at high levels or after long offline sessions. They notice when a progression curve feels off at hour 40, which is something I’d never catch in a quick playtest.
The Discord stays active throughout the day. Someone notices a balance issue, posts about it, and three other testers chime in with their experience. By the time I check the channel, there’s often a consensus forming — complete with suggested fixes and counterarguments.
Feedback that changed the game
Some of the biggest design shifts in Manu Idle came directly from tester conversations.
The smithing rework. Early smithing was a straightforward “click to craft, wait for timer” system. Testers found it boring — not because it was slow, but because there were no interesting decisions. One tester suggested tying smithing output to the quality of materials you choose to use, which opened up a whole layer of resource management. The current smithing system barely resembles the original because of that thread.
Offline summary redesign. The first version of the offline summary was just a list of numbers. “+4,382 gold, +12 Mining XP, +3 Woodcutting levels.” Testers consistently said it felt anticlimactic. What they wanted was a narrative — a sense that something had happened while they were gone. The current summary tells a story: what your character focused on, what they found, what milestones they hit. That reframe came entirely from community feedback.
The AFK timer debate. I originally planned a 12-hour offline cap. The community pushed hard for 24 hours, and their reasoning was persuasive: people who check their game once in the morning and once at night shouldn’t lose progress overnight. The 24-hour window became one of the game’s defining features.
What I’ve learned about feedback
Not all feedback is equal, and learning to filter it has been a skill in itself.
Volume matters more than intensity. One person asking loudly for a feature is just an opinion. Five people independently mentioning the same friction point is a signal. I track how many testers bring up the same issue unprompted — that’s my real priority list.
“This feels wrong” is more useful than “here’s how to fix it.” Players are excellent at identifying problems and unreliable at prescribing solutions. When someone says “mid-game feels slow,” that’s actionable data. When they say “you should add a 2x speed boost at level 20,” that’s one possible fix among many, and usually not the best one.
Testers who disagree are the most valuable. When two engaged players have opposite opinions about a mechanic, the tension usually reveals a design choice I haven’t committed to clearly enough. The debate is the point.
The trust cycle
There’s a compounding effect to building with your community. When testers see their feedback reflected in the next update, they invest more energy in thoughtful feedback. When they invest more energy, the feedback gets better. When the feedback gets better, the game improves faster, which makes testers more excited, which makes them more engaged.
This only works if you’re transparent about what you’re doing and why. When I don’t take a suggestion, I explain my reasoning. When I change something based on feedback, I credit the idea. People respect the process even when their specific request doesn’t make the cut.
The Discord as a design tool
At this point, Discord isn’t just a support channel — it’s a design tool. I post early mockups and rough ideas there before writing a line of code. The conversation that follows is essentially free user research, and it catches bad ideas before they consume development time.
I’d estimate that 30-40% of my design decisions have been directly influenced by community conversations. For a solo developer without a QA team or a design department, that’s an invaluable resource.
If you want to see what this looks like in practice, join the Discord. The alpha is still running, and there’s always something being debated.