SOLO GAME DEVELOPMENT: LESSONS FROM 2 YEARS

Two years ago I had a Trello board with forty-seven cards on it, all labeled "MVP." I was very serious about the word "minimum." I was also wrong about what minimum meant, what viable meant, and what product meant. The board is gone now. The game it described is also gone. What replaced both of those things is a much smaller game, a much shorter list, and a much more honest understanding of what solo development actually costs.

This is not a victory lap post. I have not shipped a Stardew. I have not even shipped a Pony Island. What I have done is spent two solid years working alone on games at Polylusion, putting things in front of players, making mistakes that other people warned me about and then making them anyway. If you are about to start, or you are six months in and starting to wonder if the second wave of motivation is ever coming back, this is what I have learned.

Scope creep is the thing that kills you

Every solo dev post says this. I read all those posts. I nodded sagely. I then proceeded to scope creep myself into a coma within the first six months. The reason it keeps happening to people is that scope creep does not feel like scope creep when you are doing it. It feels like having good ideas. It feels like making the game better.

Here is what it actually looks like in practice. You build a working prototype of a core mechanic. It feels good. You start thinking about what would make it feel even better. A second mechanic that complements the first. A meta progression layer because roguelikes have those. A skill tree because skill trees are fun. A second biome. A boss for that biome. Now you need a hub area to tie the biomes together. Now the hub area needs NPCs because empty hubs feel dead. The NPCs need dialogue. The dialogue needs a portrait system. The portrait system needs an art style. The art style needs to match the rest of the game, which now needs to be redrawn.

Three months ago you had a fun prototype. Now you have a design document for a 40-hour RPG that you, one person, are going to ship in two years. You will not ship it in two years. You will not ship it in five. You will get to month eighteen, look at the mountain of half-finished systems on your hard drive, and quietly close the project.

The fix is not "have more discipline." Discipline runs out. The fix is structural. Decide what your game is in one sentence before you build anything. When you want to add a feature, ask whether the sentence requires it. If the sentence does not require it, the feature does not go in the game. The sentence can change, but only deliberately, with a written reason, not because you played a great game last weekend and got excited.

I keep my one-sentence description pinned in my project folder as a text file called WHAT_THIS_IS.txt. When I open the project, that file opens too. It is annoying and that is the point.

Marketing is half the job and you will hate it

Nobody starts making games because they want to write tweets. I certainly did not. I started making games because I wanted to make games. The cruel joke of solo development in 2026 is that the actual work of making the game is maybe forty percent of the job, if you are lucky. The rest is being a publicist for a company of one, with no marketing budget, in a market that releases more than fifty Steam games every single day.

I avoided marketing for the first eight months. I told myself I would do it later, when the game was further along. When the game was further along, I told myself I would do it when there was a vertical slice. When there was a vertical slice, I told myself I would do it when the Steam page was ready. The Steam page was never ready. There is always one more screenshot that needs to be retaken, one more GIF that needs to be cleaner, one more devlog draft sitting in a folder.

The honest truth is that marketing your indie game is uncomfortable in a specific way. It requires you to publicly say "this thing I made is worth your time" before you have any evidence that it is. You have to post a GIF and ask for wishlists when no one is asking. You have to make the same announcement on six different platforms because every platform is its own walled garden. You have to look at the analytics afterward and accept that twelve people saw your post and zero of them clicked through.

What changed for me was treating marketing like a development task, not an emotional event. Mondays and Thursdays I do marketing. I make a GIF, I write a post, I update the Steam page, I respond to the small number of comments that actually appear. I do not check engagement during the day. I do not refresh the wishlist counter. The work either pays off or it does not, but at least it gets done.

If you take nothing else from this post, take this. Open your Steam page on day one of development. Not month six. Not when it looks good. Day one. Even an empty coming soon page with a placeholder logo collects wishlists from people who randomly stumble across it, and those wishlists compound over time.

Shipped beats perfect, every time

The first game I ever made as a solo dev never came out. It was a small puzzle thing. It was 80 percent done in month four. It was 85 percent done in month seven. It was 88 percent done in month eleven. Around month thirteen I quietly stopped opening the project. The remaining 12 percent never got built because the remaining 12 percent was the unglamorous work. Save systems. Settings menus. Controller remapping. Localization-ready strings. Pause menus that actually pause everything. Steam achievement integration. Crash logging.

This is the real reason most solo games never ship. Not because the developer ran out of ideas. Because they ran out of energy for the parts of the game that nobody talks about in YouTube videos. The fun part of game development is the prototyping. The brutal part is everything between "playable" and "shippable," and that gap is enormous.

The mindset shift that helped me was redefining what done means. Done is not "I have explored every interesting design idea this concept could support." Done is "a stranger can buy this, install it, play it, and not write me an email." That second definition is a lot smaller and a lot more achievable. It also forces you to ship, because the moment you let "done" mean anything more than that, you are negotiating with yourself, and you will lose.

There is a related lesson here about second-system syndrome in solo dev specifically. Every time I finish something, my first instinct is to start thinking about the bigger, more ambitious follow-up. The follow-up has all the cool stuff I cut from the first project. The follow-up is twice the scope. The follow-up will be the one that proves I can really do it. The follow-up is also the same trap as before, dressed in different clothes. If you cannot ship a small thing, you definitely cannot ship a bigger thing.

The loneliness is real

This is the part of solo dev nobody puts in the recruitment material. You spend most days in a room by yourself, talking to no one, looking at problems that only you understand, with no one to bounce ideas off of, no one to commiserate with, no one to high-five when something works. Your friends and family will support you, but they cannot meaningfully discuss why your collision system is misbehaving on the third Tuesday of March. They will nod politely and ask when the game comes out. You will say "soon."

The loneliness compounds the longer you go. The first six months feel exciting and independent. The next six months feel quiet but productive. After that the silence starts to weigh on you in ways that are hard to describe to people who work on teams. There is no water cooler. There is no shared victory. When you fix a hard bug at 11pm on a Sunday, no one sees it. The dopamine you would normally get from a coworker saying "nice" is just gone. You have to manufacture your own.

The mitigations that worked for me are unglamorous. I joined a Discord with other solo devs in roughly the same spot I was in. Not a huge public one, a small one with maybe fifteen active people. I post my dumb screenshots there. They post theirs. Sometimes someone says something genuinely useful about a problem I am stuck on, but mostly the value is just having other humans witnessing the work. I also started leaving the house once a day, deliberately, for a coffee or a walk or a grocery run that I do not technically need. The old joke that game devs do not see sunlight stops being a joke around month nine.

If you are looking for a place to start, the solo dev subreddit community is a reasonable on-ramp. It is messy and noisy and full of beginners asking the same five questions, but the regular contributors are real and they show up.

The freedom is also real

I want to balance the loneliness section with the part that actually keeps me doing this. Solo development gives you a kind of creative freedom that does not exist in any other professional context. There is no producer to convince. There is no design-by-committee. There is no marketing department asking you to add a battle pass. The game is whatever you decide it is, built the way you decide to build it, released when you decide to release it.

This sounds obvious until you have actually worked on a team and felt the constant friction of collaborative compromise. Every interesting idea on a team game gets diluted through five rounds of discussion. The version that ships is the version everyone could agree on, which is usually the safest version, which is usually the most boring version. Solo dev cuts that entire dynamic out. The weird idea you had at 2am can be in the game by tomorrow afternoon if you want it to be. That is genuinely thrilling, and it is the reason a disproportionate number of breakout indie hits come from individuals or tiny teams.

The flip side is that there is no one to stop you from making a bad call, but a bad call you have to live with is also how you learn taste. After two years I trust my own design instincts in a way I did not before, because I have made enough mistakes alone that I know what they feel like before I commit to them.

The burnout cycle is predictable

I burn out roughly every four to five months. It used to scare me. Now I plan around it. The cycle goes like this. Two months of high momentum where I am shipping features faster than I can think of new ones. One month of declining momentum where everything feels harder and the bugs are uglier. Two weeks of denial where I push harder and produce less. One week of complete shutdown where I cannot bring myself to open the project. Then a slow return.

The pattern repeats. The trigger is usually some combination of an unsolvable-feeling problem, a stretch of marketing posts that got no engagement, and a glance at a more successful indie game on Steam that makes me question why I am bothering.

What helps is not pretending the cycle will not happen. When momentum starts dropping, I stop trying to outwork it. I take three real days off, no project, no Twitter, no devlog. I play other games, ideally not in my genre. I read something unrelated to development. I let the well refill. The first day always feels like guilt. By the third day my brain starts generating ideas again on its own, which is the signal that the break worked.

The other thing that helps is keeping a running document of small wins. A screenshot that turned out well. A piece of feedback from a tester. A bug that took six hours to find. When the bad weeks come, that document is the only thing that reminds me the work is real and the progress is real and I am not actually going in circles.

What success actually looks like

The reference points get used a lot in solo dev discussions and they are worth being honest about. Stardew Valley, four years of work, then ten million copies. Undertale, multiple years of work, then a generational hit. Lucas Pope shipping Papers Please and Return of the Obra Dinn, both critical darlings, both deeply weird, both unmistakably the work of one person. These stories are real. They are also extreme outliers, and treating them as a baseline is how you set yourself up to feel like a failure when you sell two thousand copies of a perfectly fine game.

The quiet failures are everywhere and nobody writes blog posts about them. Most solo games sell in the low hundreds. A meaningful chunk sell in the dozens. Some sell in the single digits. Steam releases more than fifty games a day and the median wishlist count at launch for a solo indie is genuinely small. Knowing this in advance does not make it less painful, but it does make the painful version less of a personal indictment. It is the math of the industry, not a verdict on your worth.

Success at solo dev, defined honestly, is shipping something you are not embarrassed by, learning enough to make the next thing better, and not destroying your mental health in the process. By that definition, a lot of the people I respect most in this space are quietly successful, and they will never be the subject of a YouTube documentary.

Two years later

I am still doing this. I am still making games alone. I am better at it than I was two years ago, which is the only metric that matters week to week. The Trello board with forty-seven MVP cards has been replaced by a much shorter list of things that actually need to exist for a game to ship. The follow-up project is already nagging at me. I am trying very hard to finish the current one before I let it.

If you are starting solo development right now, the things I would tell you are simple and they are the same things every solo dev post says, which I now understand were correct and which I ignored anyway. Keep the scope small. Open the Steam page on day one. Treat marketing as work, not as an event. Ship before it is perfect. Find other solo devs to talk to. Take real breaks. Define success in a way that does not require winning the lottery.

The work is hard. The freedom is worth it. The loneliness is real and so is the satisfaction of building something that exists in the world because you, alone, made it exist. Two years in, I would still pick this over working on a team. Ask me again in another two years, and I hope I am still saying the same thing.