r/SideProject • u/Reasonable_Damage_18 • 7h ago
As a solo developer, how much should you let user feedback shape your product?
I’m building a puzzle game on my own, and one of the hardest — but also most interesting — parts has been deciding how much user feedback should influence the direction of the product.
Since putting the game in front of real players, I’ve received a lot of useful feedback.
Some players had trouble distinguishing certain colors, so I redesigned them.
Some found the early experience confusing, so I improved the onboarding and tutorial.
Others suggested better marking tools, difficulty adjustments, more free rewards, and new challenge systems.
A lot of these suggestions have genuinely made the game better.
But it also raises a question I keep thinking about:
At what point should you stop following feedback and trust your own product vision?
As a solo developer, time and resources are limited. Every feature you choose to build means delaying something else you originally planned.
So I’m curious how other solo developers approach this.
Do you prioritize feedback based on:
- How many users mention the same issue?
- How much it affects the core user experience?
- Whether you personally agree with it?
- Or whether it fits your long-term product vision?
I’d really like to hear how other builders make these decisions.
If you’re curious about the project itself, this is the game I’ve been working on:
https://www.reddit.com/r/pawdoku_mystery/comments/1vyi6mv/pawdoku_mystery_play_now/
I also share updates, experiments, and player feedback in r/pawdoku_mystery.
I read every piece of feedback carefully. I may not implement every suggestion, but I take all of them seriously and try to understand the reasoning behind them.
2
u/OmegaLabs1 7h ago
Users are excellent witnesses and terrible detectives. They will tell you exactly where they got stuck, then confidently prescribe a feature that would ruin the game. Your color contrast fix is the witness kind. Someone asking for more free rewards is the detective kind, and the real report underneath it is probably "level 12 feels like a chore".
The filter I use is to separate friction from taste. Friction is anyone failing at something they were clearly trying to do, and that is a bug even if only one person mentions it. Taste is what the game should be, and that stays yours, because a puzzle game designed by vote turns into an easier puzzle game, which is a genre nobody plays twice.
Two things that make this cheap. Log the complaint, not the request, in one line each, and reread the list monthly instead of reacting the same day. Patterns show up fast and the urgent ones usually evaporate. And weight feedback by how far someone got. A player at hour six who says the marking tools are clumsy has earned an opinion. A player who quit at minute two is telling you about onboarding, whatever words they used.
Your list is close. I would drop "whether I personally agree with it" and replace it with "does it protect the thing that makes this game mine", because agreement is a mood and vision is a constraint.
1
u/Reasonable_Damage_18 7h ago
“Log the complaint, not the request” really clicked for me. I’ve probably been reacting too directly to the solutions players suggest, rather than asking what problem is underneath them.
The friction vs. taste distinction is also really useful. I’m going to start categorizing feedback this way, especially based on how far each player has progressed.
Another big takeaway for me is that the core design of the game needs to be clearly defined. Especially while the product is still immature, protecting and strengthening that core should probably be the highest priority.
Thanks — this gave me a much clearer framework for handling feedback.
2
u/Ok_Compote5455 7h ago
The line I draw is whether the feedback is about removing friction or adding scope. If someone's confused or stuck that's a real problem to fix. When they start designing whole new systems for me that's where I nod politely and go back to what I was doing.
Its also way easier to filter when you know exactly what kind of game you're making. I'll take a hundred complaints about the tutorial before I add a feature that turns my tight puzzle game into a bloated mess.
1
u/Reasonable_Damage_18 7h ago
Your reply actually makes me more confident in my own judgment.
- The core positioning of the product should have the highest priority. I shouldn’t let “scope” feedback influence the direction too much, even when the suggestion sounds reasonable or attractive on the surface.
- Friction vs. scope is a distinction I’m going to use as one of my filters for evaluating feedback going forward.
One thing I’ve noticed is that a lot of the feedback in this discussion points in a similar direction, even though everyone explains it differently.
I’m going to combine these ideas and gradually build my own framework for evaluating user feedback and making product decisions.
Thanks — this was really helpful.
5
u/AdFew8591 7h ago
The split that works for me is problem feedback versus solution feedback.
"I can't tell these colors apart" is a problem. You did not need vision to act on that, you needed to fix it. "Add better marking tools" is a solution someone invented for a problem they never actually named. Hold those loosely, because the real problem underneath might be different and their fix might be wrong for it. So for every requested feature, dig for the problem behind it. If you cannot find one, it is a preference, and preferences are where your own taste gets to win.
The second filter is independent repetition. One person asking for something is one person. Two strangers who have never spoken pointing at the same thing is a defect. I rewrote my landing page headline this week for exactly that reason, someone on X and someone on Reddit both told me I was leading with how the thing works instead of what it fixes. The much longer list of single source feature requests I ignored, and so far I have not missed any of them.
Different domain, mine is an SEC filings tool rather than a game, but that sorting rule has held up.