About the authors

This article grew out of a talk Max and Alina gave at a local conference. It brings together Red Collar’s agency experience and a product team perspective to explain refactoring in practical business terms: what to change, when to do it, and how to calculate the cost.

Refactoring changes the internal structure of a product without changing how it behaves. That makes the work difficult to see from the outside. A development team can spend months on it while users continue to see the same product and clients wonder why so much effort appears to have produced "nothing."
 

Readable code still matters, but it isn't the main reason for most modern refactoring. The practical value is making a system faster, more stable, and more secure. Refactoring can also reduce support and development costs or prepare a product for changes that its current architecture can't handle.
 

We divide refactoring into three types: migration, optimization, and cleaning. Each solves a different problem and needs a different cost calculation.

Migration: moving to a new stack, architecture, or cloud

Migration can mean switching frameworks, languages, databases, or external services. It can also involve restructuring the architecture or moving a system to or from the cloud. This is usually the most expensive type of refactoring, but delaying it can make future product development and support even more costly.
 

One of our clients had a hybrid system that combined Java with old C++ components. Their internal team could no longer support the C++ part. We brought in a C++ developer to keep the system running in the short term, then moved the service to Java. The functionality stayed in place, while the technology became consistent with the client's internal capabilities.
 

Migration can also become necessary when the existing system blocks new features. Building a feature before migration may mean adapting it to the old system and then rewriting it for the new one. To compare the options, calculate the expected revenue from the feature and the cost of building it before and after migration.
 

The available hiring pool matters too. When a technology becomes difficult to recruit for, compare current developer rates, the time and cost of recruitment or training, and the long-term maintenance risk. A stack can continue to work while becoming increasingly expensive to support.

Optimization: making the system faster, safer, and cheaper to run

Optimization is about measurable factors such as performance, stability, and security. The most expensive part is often identifying what needs to be optimized and whether the expected improvement will justify the work.
 

Site speed has a direct effect on paid traffic and retention. If a site takes more than 2 seconds to load, users begin to leave. Speed can also improve search visibility, bringing in more organic users and reducing reliance on paid acquisition. A useful calculation should include the cost of paid and organic users, the current traffic split, the potential for traffic growth, and the performance of competing products.
 

A practical example is our Neura website. Loading speed and mobile accessibility were priorities, so we optimized all 3D models for the web and adapted them to different devices. This allowed the site to retain its animated 3D content across mobile and desktop formats.
 

Infrastructure is another source of potential savings. Identifying unused compute can already reduce costs, and even a 1% reduction in server load can add up. The calculation should compare monthly server expenses, the cost of investigating possible optimizations, and the return from reducing resource consumption.
 

Security requires a different comparison. Testing and bug bounty programs have visible costs, but a data breach or distributed denial-of-service attack can cost much more. The calculation should include the estimated loss from an incident, the possible decline in user trust or traffic, and any bug bounty payouts.

Cleaning: removing code and services that no longer earn their place

Refactoring isn't always about rebuilding or improving something. Sometimes the right decision is to remove dead code, outdated application programming interfaces, or entire product sections that people no longer use. This becomes especially important in products that have been running for a long time.
 

Unused code still creates work. Developers can change it accidentally, fix bugs that no longer matter, or spend time trying to understand it. Tracking how often inactive code is edited can help show when the accumulated maintenance work justifies cleaning it up.
 

Outdated application programming interfaces can create security and infrastructure risks. They can't always be removed immediately, especially when older versions of a mobile app still depend on them. Before retiring an interface, check its actual usage, the cost of keeping it operational, the infrastructure load it creates, and its risk level when payments or user data are involved.
 

The same logic applies to complete product sections or services. A section may receive little traffic while continuing to consume development and quality assurance time. Removing it is a visible change, so the decision should account for user visits, timing, communication, navigation, and the possible effect on search visibility.

How to decide what to refactor

Not every product needs all three types of refactoring. A minimum viable product may skip cleaning, while a long-running platform may need cleanup before migration can begin. When all three are relevant, the practical order is often:
 

Clean → Migrate → Optimize

Start by identifying what is broken, expensive, or blocking progress. Match the problem to the relevant type of refactoring, check whether another phase needs to happen first, and calculate the cost of the work. Support expenses, infrastructure spending, incident history, recruitment difficulty, traffic, and development estimates provide a stronger basis for the decision than instinct alone.
 

Refactoring isn’t mainly about clean code. It’s about running a product with fewer unnecessary costs and risks, so the team can focus on building what matters instead of constantly fixing old problems.