James Rowbotham James Rowbotham

The Reality of Solo Game Development - Freerunners Postmortem

Well, that took a long time…

I solo-made a game called Freerunners (check it out on Steam here), a precision parkour platformer built around speed, flow and shaving seconds off every run.

It was inspired by taking real-life parkour lessons and wanting to capture that feeling of hitting a route just right. I worked on the game during evenings and weekends over the years, and this year I finally released it. It hasn’t sold well, but I’m genuinely proud of how it turned out. More importantly, I learned a huge amount making it. While this wasn’t a financial success, it still had a lot of value. I didn’t bet the farm on it, I wasn’t relying on it to survive, and it’s made me a much better developer.

Looking back, there’s a lot I’d do differently. Most of the mistakes I made weren’t obvious at the time. They only revealed themselves as I got deeper into the project. This postmortem is a breakdown of those pitfalls I hit as a solo developer, and what I’ll try to consider in my future games to make things faster and smoother to build.

Key Takeaways (TL;DR)

If you only read one section, here’s what solo deving really taught me:

  • Early decisions (genre, scope, tech) will define your entire project

  • Without deadlines, your game will drift and take far longer than expected

  • If you keep replanning, you probably don't need a better plan; you need less scope

  • Get feedback constantly. Avoid becoming an echo chamber of one

  • Everything takes longer than you think, especially content

  • You are the bottleneck for everything

  • Long projects lock you into tech and outdated decisions

  • Finishing a game is a skill, but so is knowing when to stop

  • Time spent on one project is time not spent on another

  • Do you really need to do it all alone?

If you’re making a game solo, I hope what I’ve written here helps you avoid some of the same traps I ran into.

Below is a breakdown of the lessons covered in this postmortem, grouped into four key themes:

 

EARLY DECISIONS

Early Decisions Matter More Than You Think

The choices you make at the start will shape everything that follows.

A lot of us start with: “Is this fun?”

If you’re making a game as a hobby project, that's completely fine, just have some fun and learn. But if your goal is to build something that you can sell commercially, it’s worth being far more strategic with your early decisions by also asking:  “Will this be easy to develop, show off, explain, and sell?”

Things like genre, art style, scope, and presentation directly affect how long the game takes to make, how easy it is to market, and whether anyone notices it at all. The problem is, the consequences of these decisions often only show up much later in the project, when they are far harder to change. As a solo dev, you likely won’t have time or support to fix them then.

Looking back, one of my biggest early mistakes with Freerunners was the genre choice.

Parkour is a strong theme, but pairing it with a side-scrolling platformer made it much harder to market. It’s a crowded space, and more importantly, it doesn’t naturally sell the fantasy of parkour in a visually striking way.

If I had taken the same core idea and built it as a first- or third-person experience (closer to something like Mirror’s Edge), it likely would have been easier to market through screenshots and videos and potentially even been more fun.

TAKEAWAY: A good idea isn’t enough, it needs to be sellable.

 

Be Intentional With Your Time

If you don’t define what you’re trying to get out of something, it will drift, and it will take longer than it should.

When you’re working solo, it’s easy to let things bleed into each other. You start by experimenting, then keep building on top… and before long, what was meant to be temporary has quietly become part of the final game. 

Prototypes are a good example. They can serve different purposes: testing ideas, pitching, or forming the foundation of your game. The danger is mixing those up. You create something quickly to test an idea… then keep building on it… and suddenly your “quick test” has taken months and become the foundation of your game, complete with hacks and shortcuts that slow you down later.

Be intentional. Define what you want to get out of it upfront:

  • What are you trying to learn?

  • How long will you spend on it?

  • Are you throwing it away, or building on top?

Even rough answers create structure and help stop things from drifting.

With Freerunners, I never clearly separated prototyping from development. For the first year and a half, I was just experimenting. No deadlines, no clear goal. That prototype slowly became the full game without any real shift in mindset. I could have shaved a year off the project at least by simply giving myself a deadline in those early days.

Nowadays, I try to prototype ideas over 1-2 weeks with a clear goal:Is this idea worth taking forward?

TAKEAWAY:Be intentional, or it will drift and cost you time.

 

Without Deadlines, It Can Go On Forever

If there’s no deadline, there’s no reason to finish.

As a solo dev, there’s no external pressure. No one is waiting on you, and no one is forcing decisions. That sounds freeing, but it also means things can drag on indefinitely. Loose or non-existent deadlines can lead to:

  • slower decisions

  • more overthinking

  • scope creeping over time

Even rough deadlines create urgency and force progress.

TAKEAWAY: If you don’t set a deadline, your project won’t end, it will just drag on.

 

Learning vs Shipping

Trying to learn something major while shipping a game will slow you down.

When I started Freerunners, one of my goals was to learn C++. At the time, I had experience with Python and Unreal Blueprints, so moving into C++ felt like a natural next step. Using a real project to learn seemed like a great idea, and it did work. I learnt a huge amount.

However, it had drawbacks. I was trying to learn a major new skill while also finishing a commercial game. As a solo dev, if you’re stuck, the whole project stops. In my case, that slowed development down significantly, by years. 

Over time, learning and shipping also started to conflict.

I reached a point where I avoided working on and touching parts of the codebase, because I was afraid I’d break something badly and not understand why, and so ruin all the work I had put into trying to get the game finished.

If you need to learn something big, it’s often better to build a few smaller, focused throwaway projects first. Build confidence, develop good patterns, then apply that knowledge to your larger projects.

If I had done this for Freerunners, I think I could have built the game much faster.

TAKEAWAY: Don’t learn core tech for the first time inside your main commercial project, it will slow you down.

 

DEVELOPMENT REALITIES

Reduce Friction Wherever You Can

The harder your workflow is, the slower your game gets made.

Make development as simple and frictionless as possible. Every bit of friction: slow builds, awkward testing, manual steps, adds up over time. It’s easy to ignore small inefficiencies/problems early on. But over months or years, they really start to compound. 

When you’re solo, every slowdown hits the entire project. 

Invest in making development easier, for example:

  • Use source control early (e.g. Git)

  • Make it fast to test things (e.g. dedicated test levels)

  • Remove unnecessary steps from your workflow

  • Invest in tools/hardware that save time (e.g. a better PC for faster compile times)

Some may seem small, but game development is a marathon, not a sprint, and small improvements repeated hundreds or thousands of times can make a huge difference.

In Freerunners, an eye-opening example of this was lighting. I originally used baked lighting for higher visual quality, but it slowed everything down. Setting up lightmaps, waiting for bakes, and iterating on levels. Eventually, I switched away from it. The visuals were slightly less “perfect”, but development became so much faster, which mattered more. I really wish I had done it sooner

TAKEAWAY: Make it easy to build your game, your future self will thank you.

 

Replanning Is A Sign Of Overscope

If you keep making new plans, the problem might not be the plan; it might be the scope.

Repeated replanning is often a warning sign.

If every few months you find yourself creating a new plan of action: Switching planning tools, reorganising tasks, trying to find a better approach, it usually means something isn’t working. Replanning becomes a way to try to make everything fit, when the reality is simple: there’s just too much work. Not impossible, but too much for one person to deliver in a reasonable amount of time. 

Overscoping is common in game dev, but it hits harder when you’re working alone. If something isn’t being worked on, it’s not moving forward at all.

Freerunners fell into this. I kept rebuilding plans, thinking I just needed a better approach. In reality, the scope was too big, and I was trying to make up the time by working harder/longer. Cutting scope, not improving the plan, is what actually moved things forward.

Next time you feel the need to replan, step back and ask: At this speed, how long will it actually take? If the answer is too long, then cut scope aggressively: Fewer levels. Fewer enemies. Simpler systems. Less content etc

Not small trims, real meaningful reductions. It’s easy to keep adding. It's much harder to cut, but that’s how you get a game finished.

TAKEAWAY: If you keep replanning, you probably don't need a better plan; you need less scope.

 

Everything Takes Time

Even simple ideas still take a long time to build.

We tend to underestimate timelines and overestimate what we can realistically deliver, especially when working solo. Doing everything yourself and constantly switching between roles slows everything down.

Freerunners is a good example. The core game loop was simple and fast (early levels take around 10 seconds to play through, later ones around a minute), so I assumed the game would be quick to make.

I was wrong.

Even with a simple loop, I still had to design, build out the art for, and polish every level. That’s where most of my time went, not into the idea or the mechanics, but into the content creation.

I originally planned for 100 levels. After a conversation with my wife (“Are you sure 100 is a good idea?”), I cut it to 50. That decision probably saved the project.

TAKEAWAY: As a solo dev, you are always the bottleneck.

 

Working Around Your Limitations

Realistically, as a solo dev, you won't be good at everything, and that's something you have to come to terms with. It’s not necessarily a bad thing, but it will shape how you build your game. As a solo dev, you don’t get to ignore your weaknesses. You need to find ways to adapt, either by improving or by working around it. Some people struggle more with code, others with art, design, or music.

For me, it’s the art side I struggle with. I’m colourblind, so even something as simple as picking colours is a real pain.

Over time, I learned to work around it by using tools, relying on feedback, and being more deliberate with visual choices. It’s something I have to stay aware of and accept that I’ll always be slower at.

TAKEAWAY: You won’t be great at everything, so learn to adapt and work around it.

 

Step Back To See Clearly

The closer you are to your game, the harder it is to see what actually matters.

When you’re working on something consistently, it’s easy to lose perspective. Everything starts to feel important, and you can spend time on things that don’t really move the game forward. As a solo dev, there’s no real external perspective to challenge that, you’re effectively an echo chamber of one.

I'm all for chipping away at things and working on something every day. However, during this project, I realised that sometimes the best thing you can do is step away.

I ran into this with Freerunners. There was an extended stretch of time where I couldn’t work on the game due to life and work. When I came back, I looked at my plans and realised a lot of what I thought was important… just wasn’t.

That distance made it much easier to see what actually mattered, and helped me cut scope for the final push toward release.

TAKEAWAY: Sometimes you need to step away to see what actually matters.

 

Get Feedback, Even If It’s Uncomfortable

Getting other people’s perspective on your game is incredibly valuable. As a solo dev, it’s just you, so you really have to actively seek out feedback. That means putting your game in front of a range of people: friends, family, strangers, demos, Reddit. Anywhere you can get real reactions. Without that, you don’t really know how your game is landing.

It’s not easy. You’ve built this thing yourself, so when people criticise it, it can feel personal. But if you can shift how you take that feedback, it becomes incredibly useful. 

If people aren’t resonating with your game, that’s important information. It might mean the mechanics, the appeal, or the marketing need work. You can try to improve things based on feedback, but if it still isn’t landing, that’s a signal.

At that point, you can either kill the project and move on or cut the scope dramatically to something you can finish much faster. Finding that out early matters. It can save you years of building something no one connects with, even if it hurts in the moment.

I wish I had been more conscious of this while building Freerunners. I showed the game to people and had a demo out for a long time, but I didn’t push it to wider audiences like Reddit to properly test how it resonated until I fully launched it.

TAKEAWAY: Without a wide range of feedback, you risk spending years building something that isn’t landing.

 

LONG PROJECT CONSEQUENCES

Long Projects Lock You In

The longer your game takes, the more locked in you become.

As your project grows, upgrading engine versions becomes riskier. Engine developers are constantly moving forward, adding new features, tools, and workflows that could make development faster or easier. However, each upgrade can break your games systems, introduce bugs, and cost days or weeks to stabilise. Because of that, the further along you are, the harder it is to justify upgrading.

As a solo dev, this is an even harder choice. In a team, someone might be able to spare time to test an upgrade. Solo, everything else stops while you do it.

I ran into this issue on Freerunners. I started in Unreal Engine 4, and during development, Unreal Engine 5 released. There were new systems and improvements that would have helped a lot, but I didn’t think upgrading was worth the risk. Especially given how big the jump from UE4 to UE5 was.

Modern systems like motion-matching animation would have been perfect for a parkour game. But my project was too far along, so I stayed where I was. While I missed out on tech that could have improved development, upgrading would likely have added significant time and risk to the project.

TAKEAWAY: The longer your project runs, the more locked in you become, not just in your design decisions, but in your tech as well.

 

You’ll Likely Outgrow Your Own Work

The longer you work on a game, the better you get and the worse your early work will look to you.

As your skills improve, it’s tempting to go back and redo things: cleaner code, better systems, improved visuals. The problem is, this can easily spiral, and you can end up reworking old parts instead of moving forward. 

As a solo dev, this hits harder. There’s no one else to push the project forward while you refactor. If you’re redoing work, nothing new is getting built.

I felt this a lot on Freerunners. Over time, I became a much better developer, and it was obvious that parts of the game could be done better. It was very tempting to go back and improve everything. But doing that would have massively delayed finishing the game. 

At some point, I had to accept that parts of the game weren’t perfect and focus on getting it done.

TAKEAWAY: Done is better than perfect, if perfect means you never finish the game.

 

Big Picture Reflections

Work On What Matters Most

It’s easy to fall into positive procrastination. Working on things that feel productive, but don’t actually move the game forward. Tweaking juice, polishing small details, improving systems… all of it feels like progress. But often, the most important work is bigger or harder: building core systems, creating content or finishing levels.

I ran into this with Freerunners. It was tempting to polish movement or add small improvements, when what I really needed to do was block out and build levels. The game didn’t need to be better in small ways. It needed more of the game.

A useful habit is to ask:

What is the single most important thing I should be working on right now?

Then do that, even if it’s less fun.

TAKEAWAY: Don’t confuse being busy with making progress.

 

Opportunity Cost Is Real

Time spent on one project is time not spent on another. This isn’t just a solo dev problem, but you feel it more when you’re working alone. If a project takes years to complete, that’s years you’re not making something else, not learning new things as quickly, and not giving yourself more chances to succeed.

I felt this with Freerunners. The longer it took, the more I realised I could have made multiple smaller games in the same time. Each of those would have been a chance to learn, improve, and potentially succeed.

I did work on other things alongside it; Unreal Optimisation Tools for the FAB store and prototypes, but that just meant it took even longer to finish Freerunners.

That doesn’t make it a mistake. I learned a huge amount, and finishing a game is a skill in itself. But it’s something I think about much more now.

TAKEAWAY: Every project you commit to comes at the cost of something else.

 

Sunk Cost Fallacy vs Finishing A Game

Knowing when to stop and when to keep going is real tough.

The sunk cost fallacy tells us not to keep going just because we’ve already invested time. And that’s true, past effort doesn’t justify future effort. But there’s another side to this. Finishing a game is a skill in itself. And because it happens at the very end of a project, it’s something a lot of us don’t really get to practice.

As a solo dev, it’s easy to fall into either extreme:

  • continuing something for too long because you’ve already invested so much

  • or dropping projects too early and never building the skill of finishing

I thought about this a lot with Freerunners. It took a long time, and there were definitely points where I questioned whether I should keep going.

However, in the end, I’m glad I finished it. Not for any financial outcome, but because of everything else I gained. The experience, the lessons, and proving to myself that I could ship a full game solo. It made me a better developer for the next game I am making.

There’s no perfect rule here. It’s a personal judgment call. But it’s worth asking yourself:

Am I continuing because this is still the right decision, or just because I’ve already spent so much time on it?

TAKEAWAY: Finishing is a skill, but so is knowing when to stop.

 

Do You Really Need To Do It Alone?

Solo dev gives you full control and freedom, but it comes with a cost. Every decision is yours, you’re responsible for everything: every system, every asset, every problem.

Over time, that adds up. While working on Freerunners, I definitely found myself questioning whether doing everything solo was the right approach, as it really is such a huge amount of work for one person.

Keeping things small and lean by teaming up with one other person is always a possibility, but it brings its own challenges: communication, alignment, reliability, and shared vision.

However, if you can find the right person, someone you really trust and work well with, it can reduce the load, move things forward faster and help mitigate some of the pitfalls discussed in this postmortem.

Looking back, I don’t regret doing it solo. But it’s something I think about more now for future projects.

TAKEAWAY: Don’t feel you always have to do everything alone.

 

Closing Thoughts

Solo development is a great way to learn and become a better developer. This postmortem isn’t meant to put you off solo development, but to show you some of the realities, so you can be better prepared.

You’re going to make mistakes, but that’s all part of the process, and if there’s one main takeaway from all this, it’s to stop and ask yourself: 

Am I spending my limited time on the right thing, and is it something people actually want?

Answering that earlier would have saved me a lot of time.

Thanks for reading.

You can check out Freerunners on Steam here

And if you want to see what I’m working on next, check out Zombie Typing, where I’m applying what I’ve learnt.

Read More

BLOG POSTS