I thought the full codebase analysis was the product. A Reddit comment changed my mind.
I’ve been building Project MRI, a tool that analyzes an unfamiliar codebase and gives developers an architecture overview, risk analysis, repository health score, and a recommended reading order.
I thought the impressive part was the full analysis. The architecture diagram. The risk radar. The health score. All the things that make the product feel sophisticated.
Then I posted it on Reddit.
I didn’t get hundreds of comments or some huge launch. I got one simple piece of feedback: “The 5 files in order thing is the hook. The score feels secondary.” And I think they’re right. The actual problem I wanted to solve was never “developers need another code quality score.” It was the feeling of opening an unfamiliar repository and thinking:
Where do I even start?
You click through folders. Open a file. Realize you don’t understand what calls it. Open another file. Find an abstraction. Follow that abstraction somewhere else. Twenty minutes later, you have 14 tabs open and somehow understand less than when you started. That’s why one of Project MRI’s outputs is simply:
Here are the 5 files you should read first, in order.
Looking back, I think I made a common mistake. I assumed more features meant more value. But the person seeing the product for the first time immediately focused on the simplest, clearest outcome. Not: “Analyze my repository.” Not: “Give me an AI-powered code health score.”
But: “Tell me where to start.” I’m still early. I don’t have a big success story or impressive MRR number to share. But this has changed how I’m thinking about the product. Instead of asking, “What else can I add?” I’m starting to ask:
“What is the shortest path between the user’s frustration and a useful answer?” For Project MRI, that answer might be much simpler than I originally thought. If you work with unfamiliar, inherited, or legacy codebases, I’m curious:
Would knowing the 5 files to read first actually help you get oriented faster? And what would you need to see alongside those 5 files to trust the recommendation?
That Reddit comment about the "5 files in order" feels like one of those moments that quietly changes the whole product. Every developer knows the feeling of opening a repo and having no idea which file actually matters first.
I can picture someone asking ChatGPT "how do I get up to speed on a legacy codebase without reading everything" long before they know Project MRI exists. If they find something that simply answers that exact frustration it sticks in their head a lot longer than architecture diagrams do.
I'm curious if you've started hearing people describe it as "the tool that tells me where to start" without ever mentioning the rest of the analysis.
That’s exactly what I’m starting to realize. I built all the analysis because I thought developers wanted a complete picture of the codebase, but the feedback so far keeps pointing back to a much simpler problem: “I just opened this repo. Where do I start?”
What I’m trying to figure out now is what someone needs alongside those 5 recommended files to actually trust the recommendation. Would the files + a short explanation of why each matters be enough for you, or would you want to see more evidence behind why they were chosen?
A short explanation would definitely help because it lets me validate the recommendation instead of treating it like a black box.
The other thing I'd be thinking about is trust before someone even lands on Project MRI. If a developer asks ChatGPT or another AI, "What's the fastest way to understand an unfamiliar codebase?" there needs to be enough external authority and discussion around Project MRI for it to come up as a recommendation instead of only the established tools. Building the product is one part—building the signals that make people and AI trust it is a different challenge altogether.
Have you thought about how you're going to build that kind of authority as you iterate on the product?
That’s actually something I haven’t thought deeply enough about yet.
I’ve spent most of my time thinking about traditional distribution — getting developers to try it, posting where developers already hang out, and seeing whether the recommendation is useful enough that they come back.
But you’re right that discovery is changing. If developers ask ChatGPT or other AI tools how to solve a problem instead of searching Google, then being a good product isn’t enough. There needs to be enough independent discussion, usage, and evidence around the product for those systems to recognize it as a credible answer.
I’m not sure yet what the right strategy is for building that authority without manufacturing it. My instinct is that it has to start with getting real developers to use Project MRI on real repositories and creating enough genuine evidence and discussion from there.
That may actually be the bigger distribution problem than I originally realized.
You’ve hit the nail on the head—building that authentic digital footprint for AI models to scrape is the modern distribution challenge. If you want AI search engines to independently surface Project MRI as the definitive solution for legacy codebases, you need high-authority anchors.
The most effective way to build that genuine authority without manufacturing fake buzz is through strategic PR and media placement. Technology and developer-focused publications are constantly looking for unique angles, and your story of stripping away complex "code health scores" to focus on a simple "5-file reading roadmap" is perfect editorial material. Getting covered by top-tier tech publications creates undeniable public evidence and high-quality backlinks. This signals directly to both human developers and LLM scrapers that Project MRI is a trusted industry standard.
I specialize in structuring media outreach and PR strategies to create this exact kind of early-stage market authority. If you want some ideas on how to pitch Project MRI's unique hook to tech journalists to build that credible footprint, feel free to drop me a line at mumar @ growwithmumar . online. Let's connect!
I like that one comment changed what you thought the product was.
The analysis isn't the outcome people are buying. They're buying confidence about where to begin. Everything else increases that confidence, but the recommendation itself is what removes the initial friction.
That’s a much better way of putting it — confidence about where to begin. I think I was treating the analysis as the product when it may actually be the evidence that makes the recommendation trustworthy. Definitely changing how I think about what to emphasize.
Interesting.
Your reply made me think less about the recommendation itself and more about what changes once evidence stops being the product and starts becoming the thing that earns trust in the recommendation.
I don't think I can explain that line of reasoning properly in a thread without oversimplifying it.
If you're interested, what's the best email to reach you on?
shoot me an email to mfrodriguez@lanl.gov
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.