Building around the “small change became cleanup” problem - feedback wanted
Hey IH,
I’m a founder working on an existing product with a small team.
I posted earlier about onboarding new devs into an existing codebase. The related but different problem I’m trying to validate now is what happens after someone is already contributing.
A feature request or bug fix looks small at first. Then it turns into cleanup because it touches an old workflow, a fragile module, a weakly tested area, or a decision only one person still remembers.
The first piece I’m exploring is a repo scan and codebase map: what screens, APIs, services, modules, and core objects exist, and how they appear to relate.
The part I’m trying to understand now is what would make that map useful when a feature or fix is actually moving towards next release.
By the time a PR is open, the team is usually trying to answer:
• What else might this change touch?
• Is this area stable enough to change now?
• What needs a closer review?
• What context should the reviewer have before approving it?
• Could this create cleanup before release?
The core idea is to help founder-led teams working on an existing product move from “here is a map of the codebase” to “here is what this change probably needs the team to pay attention to.”
Current stage: idea validation / early product direction.
I’d love your perspective:
• Have you had a recent “small change became cleanup” moment?
• What would you expect a codebase map to show before it becomes useful during PR review?
• What would make you trust it enough to use before approving or shipping a change?
My goal is to learn whether this is a real pain for small teams with existing products, separate from onboarding or better docs.
This feels real, but I would avoid leading with the codebase map in user testing. A map is useful only after the founder already trusts the warning.
I would show 3 concrete PR cards instead:
Then ask, "would this have changed what you reviewed?" If the answer is yes, the wedge is PR risk, not repo docs.
For trust, I would also show why the tool thinks each area is risky: recent churn, weak tests, old owner, production incidents, dependency fan-out, or files repeatedly changed together. Without the why, founders will treat it like another AI code guess.
the "decision only one person still remembers" part is the real killer. a module map gets you the what, but the why-its-fragile is tribal knowledge that never lands in any scan. you trying to capture the why too or just the structure?
This feels like a real pain for small teams. The issue is not just mapping the codebase, it is knowing what a small change might quietly touch before it ships.
I’d frame this less as a repo map and more as change-impact intelligence for PRs: fragile areas, missing context, reviewer focus, and release-risk signals.
The naming/positioning matters early. If it sounds like docs or code mapping, it may feel like maintenance. If it feels like a shipping-control layer, it becomes much more valuable.
Xevoa .com would fit that broader dev workflow direction well because it gives the product room beyond mapping: impact analysis, reviewer context, and release-risk visibility.