Skip to content

Modernization

Most rebuilds are not rebuilds

The call starts with "we need to rebuild everything." It usually ends with one missing index and a database that has been holding its breath since 2019.

AP

Alex Pavlov

May 20, 2026 · 6 min read

Most "we need to rebuild everything" calls are not rebuilds. They are one slow query, one missing index, and a database that has been holding its breath since 2019. Add the index. The rewrite meeting cancels itself, and so does the line item that was going to ruin your year.

I have been writing software for eleven years and I still open the slow page, hit the profiler, and find the same thing more often than I would like to admit in writing. The system is not rotten. It is waiting on one query that nobody has looked at since the person who wrote it left.

Why everyone reaches for the rewrite

A rewrite feels clean. A diagnosis feels like homework. So the instinct, when something is slow or scary, is to declare bankruptcy on the old code and start fresh. The trouble is that the new system inherits every requirement you forgot the old one was quietly handling, and you find them one production incident at a time.

What we check before anyone says rewrite

  1. Profile the actual slow path. Not the one you assume is slow. The one the data says is slow.
  2. Look for the missing index. It is genuinely the most common single fix, and it is almost free.
  3. Check the N+1 queries hiding behind a clean-looking loop.
  4. Read the cache that is either missing or lying.
  5. Only then ask whether the foundation can hold the next feature.

When the rewrite is actually real

Sometimes the foundation genuinely cannot hold what you need next, and a rewrite is the honest answer. When that is true, we phase it. The new system grows up next to the old one, takes over in slices, and the business keeps running the whole time. Big-bang rewrites are how good teams lose a year and a few good engineers.

If Shawshank taught us anything, it is that the slow, unglamorous work behind the wall is what eventually sets you free. Same with a good refactor.

The honest version of the pitch

We make more money from a rewrite than from an index. We still lead with the index, because the fastest way to earn the rewrite later is to fix the cheap thing now and be right about it. If your system is slow but you have never profiled it, do that first, even without us. Half the time the fix is free, and a free fix is a great way to start a relationship with the people who found it.

Frequently asked

How do I know if my software needs a rewrite or just a fix?

Profile the slow path before deciding. Most performance problems trace to a missing index, an N+1 query, or a missing cache, all of which are cheap fixes. A rewrite is only warranted when the foundation cannot support the features you need next.

What is the safest way to do a real rewrite?

Phase it. Build the new system alongside the old one and migrate in slices so the business keeps running. Big-bang rewrites, where you switch everything at once, carry the highest risk of losing time and institutional knowledge.

What is the most common cause of a slow application?

A missing database index is the single most common cause we see, followed by N+1 query patterns and missing or stale caches. All three are far cheaper to fix than a rebuild.

Have a workflow that needs this?

Tell us the shape of the problem. Scoped estimate, usually within 3 to 5 business days.

Estimate project