The Cost of Rewriting Code vs. Refactoring: Indie Edition

Posted by Gemma Ellison

July 31, 2025

Code Catastrophe Averted? Rewriting vs. Refactoring for Indie Devs

Press briefing time. The situation: Your indie game is gaining traction. Exciting! But underneath the hood, the code is… well, let’s just say it resembles a plate of spaghetti after a food fight. Technical debt is piling up faster than you can squash bugs. You face a critical decision: rewrite from scratch, or painstakingly refactor? Choose poorly, and you risk derailing your entire project.

I’ve been there. More specifically, I was there. My first game, a pixel-art platformer, was built during a weekend-long game jam. It worked. Sort of. Over time, feature creep, hacks, and “temporary” solutions turned it into a monstrous, unmaintainable beast. Every new feature risked breaking three old ones.

My initial instinct? Burn it all down and rewrite. “I know better now,” I told myself. “I’ll do it right this time!” Famous last words. Three months later, I had a shiny new codebase that technically did the same things as the old one, but lacked half the original features. I’d underestimated the scope of the rewrite massively, and demoralization set in. The project stalled. Starting over felt like failure — but often isn’t.

The problem wasn’t the rewrite itself, but the lack of planning leading up to it. A rewrite should be a last resort, not a knee-jerk reaction.

So, how do you decide? Let’s break down the decision-making process.

Step 1: Assessing the Damage (Technical Debt Audit)

Before you even consider rewriting or refactoring, you need a brutally honest assessment of your technical debt. Ask yourself:

How frequently do bugs appear?
How long does it take to implement new features?
How difficult is it to understand the existing codebase?
Are there critical performance bottlenecks?
Are you using outdated libraries or frameworks?

Quantify these answers. “Bugs appear frequently” becomes “We fix an average of 3 bugs per week, taking 5 hours each.” “Difficult to understand” becomes “It takes a new team member (or myself, after a month away) at least 2 weeks to become productive.”

If your answers paint a picture of constant firefighting, slowing progress to a crawl, and relying on outdated technology, rewriting might be the only viable option.

Step 2: Defining Clear Goals (What Problem Are You Solving?)

What do you hope to achieve by rewriting or refactoring? Don’t just say “make the code better.” Be specific.

Improve performance by X percent.
Reduce bug count by Y percent.
Decrease development time for new features by Z percent.
Upgrade to a newer engine version.
Improve code readability and maintainability.

These goals should be measurable. Without clear goals, you’re flying blind, and you risk endless refactoring or a rewrite that delivers no tangible benefits.

Step 3: Estimating Time and Resources (The Painful Truth)

This is where most indie devs stumble. You must accurately estimate the time and resources required for both rewriting and refactoring. And I mean really accurately. Double your initial estimates. Seriously.

Rewriting involves:

Designing a new architecture.
Implementing existing features from scratch.
Testing and debugging the new codebase.
Migrating data (if applicable).

Refactoring involves:

Understanding the existing codebase.
Identifying areas for improvement.
Making incremental changes, testing after each change.
Documenting the changes.

Factor in distractions, unexpected problems, and the inevitable learning curve.

Step 4: Choosing Your Path (Rewrite or Refactor?)

Now, with your assessment, goals, and estimates in hand, you can make an informed decision.

Rewrite is a good option if:

The existing codebase is fundamentally flawed and unmaintainable.
Upgrading to a new engine or framework requires a complete rewrite.
The estimated time for refactoring is significantly longer than rewriting.
You have a clear understanding of the original problem and a well-defined design for the new solution.

Refactoring is a good option if:

The existing codebase is functional, but needs improvement.
You can achieve your goals through incremental changes.
You have limited time and resources.
You can break down the refactoring process into manageable tasks.

Step 5: Document, Document, Document (Your Future Self Will Thank You)

Whether you choose to rewrite or refactor, documentation is critical. Explain why the code is written the way it is, what assumptions were made, and what potential problems might arise. Use comments liberally, write clear commit messages, and maintain a design document.

Good documentation makes refactoring much easier. It allows you (or another developer) to understand the code quickly and make informed decisions about how to improve it.

Step 6: Tracking Your Progress (Avoiding Another Catastrophe)

This is where the rubber meets the road. Now that you have assessed your technical debt, defined your goals, estimated timelines, and considered documentation, it’s time to track progress.

Documenting your decision-making process and tracking your progress is essential for avoiding future “code catastrophes.” I cannot stress this enough. A simple log of what you did each day, what problems you encountered, and what decisions you made can be invaluable when you revisit the code later.

This sounds simple, but consistently keeping track of your process can be challenging. That’s why we built a journaling tool specifically designed for game developers. It helps you organize your thoughts, track your progress, and learn from your mistakes. Start documenting your journey today to prevent future coding nightmares. document your process and track your progress

Common Pitfalls and How to Avoid Them

Underestimating the Scope: As I learned the hard way, underestimating the scope of a rewrite is a common mistake. Be realistic about the amount of time and effort required. Break down the rewrite into smaller, manageable tasks.
Over-Optimizing: Don’t get bogged down in premature optimization during refactoring. Focus on improving code readability and maintainability first. Optimize only when you have identified a specific performance bottleneck.
Lack of Testing: Test your code thoroughly after each change, whether you’re rewriting or refactoring. Automated testing is your friend.
Ignoring Feedback: Get feedback from other developers, if possible. A fresh pair of eyes can often spot problems that you’ve missed.

The decision to rewrite or refactor is a complex one. There’s no one-size-fits-all answer. But by following these steps, you can make an informed decision and avoid a code catastrophe. Good luck!