I turned down a $40K rewrite contract. The logs told me why.

The call was straightforward. A client wanted their Bitrix shop rewritten from scratch.

28,000 SKUs. 1C sync, three delivery regions, eight years of order history. The whole thing was running slowly and bleeding developer hours. They'd put a number on the table — around $40K, three months — and wanted a modern stack. I was the natural fit.

I asked for two days instead.

Why I didn't just say yes

I can rewrite things. I like clean code. When a client shows up with a real budget and the latitude to make architectural decisions, the professional instinct is to take the contract.

What stopped me was a single sentence: "Bitrix is holding us back," with nothing attached to it.

That's not a diagnosis. It's a feeling, and feelings can point to twenty different problems. I asked for server access and last year's revenue report. They sent both.

What two days in the logs looked like

The catalog page was running 40 SQL queries per visitor. Not because Bitrix is a bad platform — because four years ago, someone decided facet counts should be computed live on every page load. The business had tripled in SKU count since then. Nobody had revisited that decision.

LCP on the catalog: 4.2 seconds. Not from the stack — from one specific piece of code on one specific page.

There was also this: the database was 180GB. 140GB of that was session history that had never been swept. The application was hauling dead weight nobody had noticed.

Bitrix wasn't the problem. Bitrix was doing what it was told to do. It just had been told to do things badly for four years straight.

The conversation I didn't want to have

Telling a client the stack isn't the problem is uncomfortable. Especially when they've already built a mental image of the new site, the clean codebase, the fresh start.

I told them straight: a rewrite for $40K buys clean code, but it doesn't fix any of what you've described as "Bitrix holding us back." The slow catalog page isn't a platform problem. It's a specific query that needs fixing. That query will be just as bad if you write it in Node.

Three seconds of silence.

"So what do you suggest?"

What we built instead

We split the work into two lists: what actually needed to change, and what was better left alone.

The backend stayed on Bitrix. Orders, pricing rules, 1C sync — working code that makes money. Don't touch it without a diagnosis.

The catalog moved to Elasticsearch. An indexer job runs every 15 minutes, pulls from Bitrix in batch, builds the search index. Those 40 SQL queries per page became one Elasticsearch query.

A Next.js frontend on top. SSR for SEO-critical pages, client-side filtering for the rest. The old Bitrix templates kept serving checkout and account pages — because they worked fine.

Six weeks instead of six months.

Numbers from the first month

LCP on catalog: 1.4 seconds, down from 4.2. Mobile conversion: +23%. Google indexation held flat — we preserved all URLs. Hosting costs dropped because Elasticsearch absorbed the database load.

The client called three months later not with a complaint, but with the next project.

That's when the difference between "technically correct" and "correct for the business" clicked for me. The rewrite would have been technically correct. It wouldn't have been correct for their timeline or their budget.

When rewriting is actually the right answer

I'm not anti-rewrite. Sometimes it's the only path forward.

When technical debt has spread to every layer and new features take five times as long as they should. When the team that understood the codebase has left and nobody can explain why half of it works. Or when the business model has genuinely changed — not "we want a nicer frontend," but actual new use cases the old architecture can't support.

But "it's slow and we hate it" without numbers isn't a case for a refactor vs rewrite decision. It's a case for a diagnosis.

Three questions I ask at the start of any rewrite conversation now:

First — what's specifically slow, and do you have numbers?

Second — if we fix just that, how long does it take compared to a full rewrite?

Third — what happens to the business during the six months we're rewriting?

If the first question doesn't have a real answer, you need a diagnosis before you need a quote.

The real cost of a rewrite isn't in the contract. It's six months where nothing ships, while your competitor keeps moving. And it's the technical debt in the new stack that starts accumulating from commit one.

Sometimes a $40K rewrite is $40K spent in the wrong direction.