Before You Rewrite the App, Prove What Is Actually Broken

July 19, 2026

A struggling software project often reaches the same conclusion:

We need to rewrite it.

The code is difficult to understand. Bugs keep resurfacing. Releases feel dangerous. The original developer may be gone. New features take longer than expected, and every change seems to break something unrelated.

A rewrite can feel like the cleanest solution. Start over with a modern framework, a better database, clearer architecture, and none of the decisions that created the current mess.

Sometimes that is exactly what the project needs.

But “rewrite it” is also one of the most expensive conclusions a team can reach before it has gathered enough evidence.

My public work through Bill Vivino Technology includes new applications, published mobile products, production takeovers, backend integrations, app stabilization, and the restructuring of systems that had outgrown their original foundations. Those experiences have reinforced a practical rule: the first job is not to defend the existing code or condemn it. The first job is to determine what is actually failing.

A Rewrite Is a Business Decision Disguised as a Technical Decision

A rewrite is rarely just a coding project.

It affects:

• The release schedule
• Existing customers
• Internal operations
• Data migration
• App Store and Google Play distribution
• Backend compatibility
• Integrations
• Testing
• Training
• Support
• Future feature development

The old system usually cannot disappear while the new one is being built. It continues receiving bug fixes, security updates, operating-system changes, and business requests.

That means the company may temporarily fund two products:

1. The application it currently depends on
2. The replacement application that is not yet ready

The technical appeal of a clean codebase can hide this operational reality.

A rewrite should therefore be justified by more than developer frustration. The expected value must outweigh the cost and risk of replacing a working, partially working, or poorly understood system.

Ugly Code and Broken Architecture Are Not the Same Thing

Some codebases are unpleasant but operationally stable.

They may contain duplicated logic, inconsistent naming, large files, old libraries, or patterns the current team would not choose today. Those problems increase maintenance costs, but they do not automatically justify replacing the system.

A deeper architectural problem looks different.

Examples include:

• The data model cannot represent current business requirements
• Security boundaries are fundamentally unreliable
• Core workflows depend on contradictory sources of truth
• The chosen platform cannot support a required capability
• Every feature requires modifying tightly coupled systems
• The system cannot be deployed or tested safely
• Performance limitations cannot be corrected within the current design

The distinction matters.

Messy code can often be improved gradually. A structural mismatch between the software and the business may require rebuilding a subsystem or replacing the application.

The investigation should identify which problem the company actually has.

Stabilization Creates the Evidence Needed for a Decision

Before approving a rewrite, I prefer a stabilization phase.

Stabilization does not mean committing to the existing architecture forever. It means reducing immediate risk while learning how the system behaves.

The work may include:

• Making the application build consistently
• Documenting environments and deployment steps
• Restoring useful logging
• Adding crash reporting
• Fixing the highest-impact defects
• Identifying authentication and permission boundaries
• Mapping important data flows
• Reviewing database relationships
• Tracing external integrations
• Locating duplicated business logic
• Establishing a repeatable release process

This work has value even when the eventual decision is to rebuild.

The team gains a clearer specification of the real product, including undocumented behavior that users and internal staff already depend on.

Without that investigation, a rewrite may reproduce the same mistakes in cleaner code.

The Existing Application Is Part of the Specification

Teams often assume they already know what the replacement must do.

Then development begins, and hidden requirements emerge.

A field may look obsolete but feed a report. A status transition may trigger a notification. A mobile screen may support a workflow nobody documented. An administrator may depend on a manual override that appears inconsistent but exists for a valid operational reason.

The current system contains years of accumulated business decisions.

Some are bad. Some are accidental. Some are essential.

A rewrite team must distinguish among them.

Written requirements alone are rarely enough. The true specification may be distributed across:

• The existing application
• The database
• Backend jobs
• Support tickets
• User habits
• Administrative tools
• Analytics
• Integration behavior
• Institutional knowledge

Replacing software before recovering that knowledge creates a serious risk: the new product may be architecturally cleaner while being operationally incomplete.

Rebuild Boundaries, Not Necessarily the Entire Product

The decision does not have to be “keep everything” or “replace everything.”

Often, the strongest path is a controlled replacement of specific boundaries.

A team might:

• Keep the database but replace the mobile application
• Keep the user interface while replacing a fragile API
• Introduce a new authentication layer without rewriting business workflows
• Move one high-risk subsystem behind a new service
• Replace a legacy administrative interface while preserving stable backend logic
• Build new features in a cleaner module while gradually retiring old code

This approach is less emotionally satisfying than declaring a total reset. It is often more commercially sensible.

The goal is not to preserve old code for its own sake. The goal is to isolate the parts creating disproportionate risk and replace them without discarding stable behavior unnecessarily.

When a Rewrite Is Justified

A rewrite becomes more reasonable when several conditions are true.

The current system may be the wrong foundation when:

• Its core data model blocks the required product
• Security cannot be repaired confidently
• The platform is unsupported or prevents distribution
• Critical logic is effectively untestable
• Normal changes repeatedly require dangerous cross-system modifications
• Operational knowledge has been recovered and documented
• The replacement can be delivered in controlled stages
• The business can support parallel maintenance during the transition

Even then, the rewrite should have a migration strategy.

“How do we build the new system?” is only half the question.

The other half is:

How do we move users, data, workflows, integrations, and operational responsibility without creating a second crisis?

A credible rewrite plan includes both construction and transition.

AI Makes Premature Rewrites More Tempting

AI coding agents can generate large amounts of replacement code quickly.

That changes the economics of implementation, but it does not remove the need to understand the existing product.

An agent can scaffold a new mobile app, reproduce screens, create API routes, define database tables, and migrate repetitive code. What it cannot infer reliably is which undocumented behavior the business still needs.

AI can make the new system appear complete earlier than it really is.

A convincing interface is not proof that the application preserves:

• Authorization rules
• Data history
• Exception workflows
• Notification timing
• Offline behavior
• Integration contracts
• Administrative recovery paths
• Failure handling

The faster code can be generated, the more disciplined the discovery process must become.

AI reduces the cost of typing the replacement. It does not reduce the cost of choosing the correct replacement.

A Practical Software Rescue Process

A sensible rescue effort can be organized into four stages.

1. Establish Control

Make the system build, run, deploy, and report failures consistently. Secure access to source code, infrastructure, stores, domains, databases, and external services.

2. Map the System

Trace the critical workflows from the interface through authentication, APIs, persistence, background processing, and integrations.

Identify where business rules actually live.

3. Stabilize the Highest-Risk Paths

Fix the defects that threaten users, revenue, security, data integrity, or release capability.

Avoid broad cosmetic refactoring that does not reduce operational risk.

4. Decide With Evidence

Classify each major area:

• Keep
• Refactor
• Isolate
• Replace
• Retire

The result may be a rewrite. It may be an incremental modernization plan. It may be a smaller stabilization effort than anyone expected.

The important point is that the conclusion follows the investigation.

The Cheapest Rewrite Is the One You Avoid for the Right Reasons

Avoiding a rewrite is not always conservative.

Sometimes it is simply accurate.

A focused stabilization effort may restore confidence, reduce release risk, and make continued development practical. In other cases, the investigation confirms that the foundation is fundamentally incompatible with the product’s future.

Both are useful outcomes.

The failure is deciding first and investigating afterward.

Conclusion

A troubled application should not be protected because developers invested time in it.

It should not be discarded because the code is frustrating.

The correct decision depends on the system’s actual risks, the business requirements it must support, and the cost of transitioning from the current product to something better.

Start by stabilizing the environment. Trace the important workflows. Recover the hidden specification. Separate unattractive code from structural failure. Then decide which boundaries should be preserved, refactored, or rebuilt.

A rewrite can solve the right problem.

But first, prove that the problem is the application’s foundation—and not an incomplete understanding of the system already in front of you.

How Bill Vivino Technology Can Help

If you have inherited a troubled application, Bill Vivino Technology can inspect the codebase, stabilize critical workflows, and identify which boundaries should actually be rebuilt. Contact Bill Vivino Technology to discuss an existing mobile app, backend, vendor build, or technical rescue project.