Skip to main content

Every codebase has code
nobody wants to touch.

Refactron exists to change that.

Built so you can refactor the old code and prove nothing broke.

— Om Sherikar, founder

Founder · Origin

Built by Om Sherikar.

Portrait of Om Sherikar, founder of Refactron
Om Sherikar, founder of Refactron.
role:
founder · solo
building:
refactron · v0.5.x

The moment

At a hackathon, I watched a team avoid an entire part of their codebase. Nobody wanted to risk breaking it. That moment stuck with me.

I looked for a tool that would actually go in, fix the legacy code, and prove nothing broke. Couldn't find one.

So I built one.

  • 3,500+ PyPI downloads
  • No paid marketing
  • Industry beta users
  • India Ascends · Lightspeed
  • F6S founder grant
Follow on XConnect on LinkedIn

Context

The Problem.

Most production codebases carry significant technical debt, but refactoring them is often avoided.

  • Manual refactoring is slow, expensive, and risky.
  • Automated tools focus on generation without guaranteeing correctness.
  • Teams postpone structural improvements, making codebases harder to maintain.
~/legacy-monolith5 findings

› refactron analyze .

✓ scanned 1,284 files · 8.2s

[ERR ]Circular dependency

module_a imports module_b; module_b imports module_a.

[WARN]Duplicated code

847 lines duplicated across 12 files.

[WARN]High complexity

Cyclomatic complexity 28 (threshold 10).

[INFO]Test coverage

38% overall.

[ERR ]Technical debt

Overall risk flagged as high.

─ 2 errors · 2 warnings · 1 info

Analysis pipeline

5 stages

  1. Analyze the codebase

    Structure and dependencies are mapped without modifying files.

  2. Detect patterns

    Architectural patterns and hotspots surface as readable findings.

  3. Refactor opportunity

    Example: extract an interface (low risk) to reduce coupling between modules.

  4. Verification

    Behavior checks pass, including your existing test suite.

  5. Ready for review

    You get a clear diff and rationale before anything ships.

How I think about it

My Approach.

Refactoring as a structured engineering process, not a one-shot automation problem.

  • Analyzes code structure and identifies targeted improvements.
  • Proposes incremental refactors that preserve existing behavior.
  • Makes refactoring predictable, reviewable, and safe.

Principles

What Safe Means.

Safety isn't a claim — it's a set of constraints I built Refactron around.

01Read-only first
READ
WRITE

Read-only analysis by default

No changes are made without explicit approval.

Scan and understand the codebase first. Nothing is written until you choose to apply a change.

02You approve every change
PROPOSED
APPROVED

Human-in-the-loop refactoring

Every change requires explicit approval from developers.

You review proposals like any other PR. Nothing lands without your sign-off.

03Proof, not hope
syntaxpass
testspass
invariantspass

Verification to preserve behavior

Automated checks ensure functional equivalence.

Checks run against your tests and invariants so you see evidence before merge.

04Small, reviewable steps
01
02
03
04
05

Small, incremental changes

Targeted improvements instead of large rewrites.

Each step stays scoped and clear instead of one risky sweep.

05Walk it back

Rollback support

Clear documentation and easy reversal for every change.

Undo a changeset quickly when you need to reverse course.

A letter

Why I'm building Refactron.

The tools that existed could find legacy code, or generate new code. None of them could actually refactor the old code and prove it was safe.

That gap bothered me enough that I couldn't leave it alone.

Om

Questions, or want to learn more?

Get in touch