A fair way to support a solo developer
Wishlists, bug reports, and patience are real support. So is paying for the game. A checklist that stays decent.
Supporting a solo developer is not a personality. It is a set of ordinary actions that help a person ship and stay afloat, plus a few actions that feel supportive and mostly add noise. You can be a good audience without joining a fandom. The work is the point. The person is not your employee, your friend by default, or a content machine because you paid once.
Pay for the thing if you are playing it
The cleanest support is buying the game through a channel that pays the maker, and not waiting for a leak, a ripped build, or a video long enough to replace play. A wishlist is support only when the store treats it as demand and you are actually willing to buy. What an indie price tag is trying to say is about reading that number fairly. Paying a fair price for a finished evening is enough. You do not owe a second purchase of the soundtrack, the art book, and the tip jar unless you want them. Wanting them is real support too. Guilt is not.
Bug reports that an adult can use
A useful report says what you did, what you expected, what happened, and which version you were on. A screenshot or a short clip helps if it shows the failure. A message that says this sucks does not. How to read patch notes from a tiny studio tells you whether your bug is already listed. If it is listed, a duplicate pile is optional. If it is not, one clear note can save a week. Do not demand a same-day fix. A solo developer is also the person answering mail, building the next level, and living a life. Triage is allowed.
Public talk
Recommend the game to a specific person who might like it. A precise recommendation is worth more than a blast. Review it, if you review, with the same honesty you wanted from the store page. Praise the part that worked and name the part that did not, without theater. Do not review-bomb a change you dislike in a live game, and do not organize a pile-on. Why Small Teams Make Memorable Games assumes the team gets to keep making things. Harassment makes that less likely. Enthusiasm with a boundary makes it more likely.
Patience and the boundary
Early access moves slowly when one person is doing the art, the code, and the support. You can stop playing until a patch. You can ask for a refund if the store's own rules say the purchase was not what you were sold. You cannot require friendship, personal news, or a feature that exists because you thought of it. Suggestions are gifts, and gifts can be declined. A Checklist for Judging a Demo or Early Access Game is how you decide to enter that bargain. Enter it eyes open, or wait for the finished build.
What not to call support
Quoting their revenue back to them, speculating about their health, or policing how they spend a weekend is not support. Neither is piracy paired with a nice comment. Be a customer with manners and, if the game earned it, a person who tells another person. That is a complete contribution.
Frequently asked questions
Is a wishlist as good as a purchase? No. It is a maybe. A purchase, or a recommendation that leads to one, is the support that pays for the next month of work.
Should I message them my feature idea? One clear suggestion is fine. A design document in their inbox is a chore. They may already have a plan that does not include your idea, and that is allowed.
What if I cannot afford the game? Wait for a sale, play a demo, or skip it. Do not treat a solo developer as the person who has to comp the hobby. There will be other games.
Steps
- Buy the real build: Pay through a channel that pays the maker if you are going to play, instead of substituting a rip or a maybe.
- Report bugs cleanly: Include version, steps, and what you expected. Skip insults and duplicate reports of listed issues.
- Recommend precisely: Tell one person who might actually like it. Keep public criticism about the work, not the human.