← Build log

When It's Time to Rewrite: A Solo Builder's Decision Framework (and Why We Picked Rust)

May 2026
SoloBuilderRewriteRustTauriElectronTechDebtDecisionFramework

The exact assessment we ran on our Electron + Swift codebase, the eight criteria we scored against, and the rewrite decision rule that says “yes, do it” or “no, stop being romantic about it.”

Published: May 2026 Tags: #SoloBuilder #Rewrite #Rust #Tauri #Electron #TechDebt #DecisionFramework

The “So What?” - Why You Should Care

Bottom Line Value: A concrete decision framework for “should I rewrite this thing” with specific numbers, a scoring sheet you can copy, and a stop-rule that protects you from rewriting out of frustration.

What You’ll Gain:

  • An 8-criteria assessment you can run on your codebase this weekend
  • The specific code-size threshold below which a rewrite is realistic for a solo builder
  • A “carry forward” list — what you should never rewrite even when you rewrite
  • The framing that helps you tell the difference between “this needs a rewrite” and “I’m just tired of this code”
  • ROI: Either you decide YES and start the rewrite with eyes open, or you decide NO and save yourself 3–6 months of wasted work

Who This Helps: Solo builders staring at a codebase that hurts every time they open it. Anyone who’s said “I should just rewrite this” three times and wants to know if they’re right.

Why Bother: Rewrites are the most expensive decision a solo builder makes. Wrong-yes costs you 3–6 months. Wrong-no means you keep paying compounding tax on bad foundations. There’s no neutral; there’s only “decide deliberately” or “decide by accident.”

TLDR: The 8-Criterion Decision Sheet

Run your codebase against these. Score 1–5 on each (5 = “this is screaming at me to rewrite”):

  1. Bundle/install size is 3× larger than alternatives (5 if yes)
  2. Idle memory is 2× larger than alternatives
  3. You can’t add a feature without breaking three others (the integration reliability problem)
  4. The code surface is small enough to rewrite (under 20k LOC of core logic for a solo builder)
  5. Your stack locks you to one platform when you need cross-platform
  6. Debugging is dominated by console.log archaeology (not by genuine algorithmic complexity)
  7. You have specific carry-forward assets that survive the stack change (algorithms, content, design)
  8. You’d choose a different stack today if starting from scratch

Decision rule: Score ≥ 30/40 → rewrite is justified. Below that, you’re being romantic.

We scored 36/40. That’s the decision.

The Moment You’re Probably In

You open your editor on Monday morning. The codebase is 2 years old. The Electron app launches in 4 seconds and idles at 180 MB. The Swift subprocess works on macOS only and breaks unpredictably on macOS 15. You have 194 console.log statements you keep meaning to clean up. The last three features each took 2x longer than expected because something unrelated broke.

You think the same thing you’ve thought a dozen times: I should just rewrite this.

And then you stop, because:

  • The cost is months you don’t have
  • You’ve heard the “second-system effect” warnings
  • Your friends will say “rewrites always fail”
  • You’re not sure if you’re right or just tired
  • You have users (or beta testers) and you don’t want to disrupt them

If any of this sounds familiar, you don’t need a rewrite yet. You need a decision framework. Here’s the one we used.

Step 1: The Honest Assessment (90 minutes)

Score your current codebase on these eight criteria. Be specific with numbers — vibes will lie to you.

Criterion 1: Bundle/install size

What’s your installed size? Compare to similar products built on lighter stacks. Our number:

  • VoiceCatcher v0.4 (Electron + Chromium): ~350 MB installed
  • Reference: a Tauri-based equivalent: ~150–180 MB
  • Multiplier: 2.0–2.3×

Score 5 if you’re ≥3× the reasonable alternative. Score 3 if 1.5–2.5×. Score 1 if you’re competitive.

Criterion 2: Idle memory

Open Activity Monitor. Launch your app. Wait 30 seconds. Note RSS.

  • Ours, idle: 120–180 MB
  • Reference, idle: 50–60 MB
  • Multiplier: 2–3×

Score 5 if ≥2.5×.

Criterion 3: Integration reliability

Last 10 features you added — how many broke something else? Be honest.

  • Our number: 5 of 10 features caused regressions in unrelated areas
  • That’s ~50% integration reliability

Score 5 if it’s <60%. Score 1 if it’s >90%.

Criterion 4: Code surface size

Run cloc or tokei on the core logic (not deps, not generated code).

  • Our number: ~13,000 lines TypeScript + 1,628 lines Swift = ~14,600 LOC of core logic

The honest rule for solo builders: under ~20,000 LOC is rewritable in 6–12 weeks. Over 50,000 is not, for one person. Score 5 if you’re under 20k. Score 1 if you’re over 50k.

Criterion 5: Platform lock-in

Will the next 12 months require platforms your current stack can’t support cleanly?

  • Our case: macOS-only Swift CLI for audio capture. Windows port = full Swift CLI replacement anyway.

Score 5 if the lock-in blocks something you’ll need within 12 months.

Criterion 6: Debugging dominated by archaeology

Open your editor. Search for console.log (or your language’s equivalent). Count them.

  • Ours: 194 console.log statements, many of them with emojis (”🎤 starting recording”, ”✅ transcription complete”)

If most of your debugging is reading log breadcrumbs rather than reasoning about the algorithm, your structure is the problem, not the bug. Score 5 if you have >100 console.logs and use them daily.

Criterion 7: Carry-forward assets

This is the criterion that protects you from over-rewriting. What in the current codebase has real value independent of the stack?

For us:

  • 1,722 lines of NLP formatting code (tuned over 12 months — see post #139 on why we kept this verbatim)
  • 131 blog posts (years of SEO compound)
  • React component library (~3,500 LOC of well-tested UI)
  • User stories, acceptance criteria, error catalog

Score 5 if you can name 3+ specific assets that will survive the rewrite. Score 1 if everything in the current code is replaceable.

Criterion 8: Would-you-choose-it-today

If you were starting from scratch this morning with what you know now, would you pick the same stack?

For us: no. We’d pick Rust + Tauri for the desktop tier, no question. The original Electron choice was 2023’s “what’s fast to ship.” It’s not 2026’s “what we want to maintain.”

Score 5 if “absolutely not.” Score 3 if “I’d consider alternatives.” Score 1 if “yes, this is still right.”

Step 2: Add Up Your Score

Add the eight numbers. Out of 40 possible:

  • 30+: Rewrite is justified. Start planning. (We scored 36.)
  • 20–29: Genuine ambivalence. Probably refactor instead. Address the worst 2–3 criteria first.
  • Below 20: You’re not bored, you’re not romantic — you’re frustrated. The fix is rest, not a rewrite. Take a week off the codebase, then re-score.

The stop-rule: if your score is under 30, you do not get to rewrite. Period. Re-score after 30 days if circumstances change.

Step 3: The Carry-Forward List (the asset you protect)

Before you write a single line of new code, list everything that survives the rewrite:

# Carry-Forward Inventory

## Code that survives (kept verbatim or near-verbatim)
- [specific file/module] — [why it's irreplaceable]
- [specific file/module] — [why it's irreplaceable]

## Content that survives
- [blog posts, docs, assets]

## Design that survives
- [component library, design tokens, UX patterns]

## Knowledge that survives
- [PRDs, user stories, error catalogs, acceptance criteria]

## What's explicitly being discarded
- [the thing you're rewriting AWAY from]

This list does two jobs:

  1. Protects you from rewriting things that work (the second-system effect lives here)
  2. Constrains the new architecture to be hospitable to the assets you’re keeping

Our list:

  • Kept: 1,722 lines of TS formatters (carried into the Rust app as TS modules invoked from the frontend)
  • Kept: 131 blog posts (literally cp -r into the new repo)
  • Kept: React component library (migrated to the Tauri webview)
  • Kept: PRD structure and audit-block discipline
  • Discarded: Swift CLI subprocess, Electron, Electron Store, JSONL files, all 194 console.logs, the dual audio path

Step 4: The Decision Rule for the Stack

Once you’ve decided “yes, rewrite,” you have to pick what to rewrite into. We used three criteria:

  1. Does it solve the worst criterion that drove the rewrite? Ours was platform lock-in + bundle bloat. Rust + Tauri solves both.
  2. Is it boring enough? Boring stacks have docs, working examples, and Stack Overflow answers. Rust + Tauri 2 is just over the “boring enough” line.
  3. Can you carry forward the most valuable assets? Tauri embeds a webview, which means your existing React/TS code survives. That mattered.

Don’t pick a stack because it’s exciting. Pick it because it cleanly solves the specific criteria you scored 5s on, and because it doesn’t force you to throw away your carry-forward list.

What This Doesn’t Fix

  • The first month of any rewrite is slow. Setup, scaffolding, getting CI green. Plan for it. Don’t panic.
  • A rewrite doesn’t fix product-market fit problems. If users don’t want your app, a faster version of it doesn’t help.
  • You will be tempted to add features during the rewrite. Don’t. Parity first, features after.
  • Some assets will resist being carried forward even when you wanted them to (we found some React components that needed re-styling for Tauri’s webview rendering). Budget for friction.
  • Your existing users may not care that you rewrote anything. Internal-feeling wins (cleaner code, lower memory) don’t drive adoption. Plan the user-visible story before the rewrite, not after.

Try It This Week

Saturday morning (90 minutes):

  • Score your codebase on the 8 criteria. Be specific with numbers.
  • Add it up. Write the total in a doc.

Saturday afternoon (30 minutes):

  • Write the carry-forward inventory. Even if your score is below 30 — the inventory is useful regardless.

Sunday afternoon (60 minutes):

  • If score ≥ 30: write a one-page “rewrite hypothesis” doc — what stack, why, what timeline you’ll hold yourself to (we used 12 weeks; see post #136 for the methodology)
  • If score < 30: write a “refactor list” instead — the worst 3 criteria become your next sprint

Two weeks later:

  • Re-score. Decisions that survive two weeks of consideration are real decisions.

That’s the whole framework. The point isn’t to talk yourself into a rewrite. It’s to make a deliberate decision either way and know why.

The Takeaway

Most rewrites that fail were never properly decided. Someone got frustrated, started typing, and 3 months later they had two half-working codebases.

The fix is structural: score the criteria, list the carry-forward, write the hypothesis, wait two weeks. If it still holds, do it with eyes open. If it doesn’t, you saved yourself months.

We scored 36/40, listed 4 carry-forward assets, wrote the hypothesis, and started the rewrite 14 days later. The 14-day wait isn’t bureaucracy — it’s the test that separates rewrites driven by clarity from rewrites driven by frustration.

If you’ve thought “I should just rewrite this” three times in the last month, this is the weekend to find out if you’re right.

Coming up next: post #136 — PRD-driven development for solo builders. Once the rewrite decision is made, how do you keep yourself honest about scope without slowing down to enterprise-PM pace?