Every product manager or engineer who’s inherited someone else’s codebase knows the question:
Do we try to enhance what’s here—or is it cleaner to rewrite from scratch?
In my career, hindsight has always said the same thing: we should have started fresh. Every “let’s just patch it” decision ballooned into painful tech debt, endless rework, and a slower path to value.
But saying “rewrite” is easy. Proving it is hard. Nobody wants to be the one asking leadership for 6–12 months of greenfield work without a data-backed rationale.
That’s why I started experimenting with ways to make this decision objective, not gut-driven.
The Journey
I first began by drafting prompts that could analyze a repo in depth: complexity, dependency health, test posture, architecture risk. I tried a few different permutations—sometimes asking for too much in one pass, other times too vague to be useful. The goal was clear: get a repeatable framework that produced the same kind of due diligence you’d want if you were investing in a company, but scoped down to “should I touch this code or torch it?”
After a handful of iterations, I broke it down into two clean phases:
- Phase 1 – Discovery: Lightweight, repo-local evidence gathering. Complexity math, dependency scans, obvious red flags. Think of it as your triage.
- Phase 2 – Detailed Analysis: Deeper dives, comprehensive complexity quantification, risk scoring, and production readiness checks. This is where you get the kind of executive-summary material that actually supports a recommendation.
This split made the whole process tractable. Instead of overwhelming one big prompt, I now had a tight flow that was easy to run inside VS Code with Copilot Chat.
Where I Landed
The result is a small but powerful prompt pack, now published here:
→ Repo Tech Due Diligence Prompt on HuggingFace
- It’s open, structured, and auditable.
- It forces the model to output tables, paths, and exact lines—no hand-waving.
- And it makes space for the engineer or PM running it to see the evidence directly and judge for themselves.
I’m not claiming it’s perfect, but it’s a starting point. For me, it finally feels like I can walk into a codebase, run a consistent playbook, and get an answer that’s more than “my gut says rewrite.”
Why Share This?
If you’re a product manager trying to weigh the roadmap cost of carrying legacy code, or an engineer staring at a repo you’ve just inherited, I’d encourage you to take a look. Run Phase 1, see what surfaces, then dive into Phase 2 if you need a fuller picture.
At minimum, you’ll get cleaner evidence to back up your instinct. At best, you’ll have a reusable due diligence framework for every future “is it worth enhancing, or should we rewrite?” moment.
Check it out here: Repo Tech Due Diligence Prompt on HuggingFace
