Key insights from the feedback
There was one word that came up repeatedly in the feedback
“Monorepo.”
- Analysis stopped in the monorepo
- Since only one repo can be selected, MSA-structured projects become fragmented
- I couldn't bundle a project spanning multiple repos into a single one
At first, I thought these were edge cases.
But as the feedback piled up, it became clear. This wasn’t an exception—it was the reality for developers in the field.
Turborepo, Nx, pnpm workspace
These days, the more robust a project is in practice, the more likely it is to be a monorepo or split into multiple repos.
So I took a look at the portfolio services available on the market.
Most of them were stuck in a “profile + repo list” format.
They either show only one repo at a time or limit themselves to superficial metrics like the number of commits.
I wondered why that was.
To properly analyze a monorepo, there are more than just one or two problems to solve.
Context limitations, workspace detection, tracking internal dependencies, grouping tech stacks, and even cost structures
It’s not a matter of solving just one; they all need to be addressed simultaneously
That’s why many services avoid this area
I think this part is very difficult
But I believe that only by understanding projects that are complex, span multiple repositories, and reflect real-world practice can we win in the competition
That’s why the next version will properly address both monorepos and multi-repos.
- Automatic workspace detection
- An experience that bundles multiple repos into a single project
- Differentiated analysis by project type (backend/frontend/infrastructure/data)
To everyone who provided feedback, thank you sincerely.
Posted Apr 20, 2026, 4:39 PM UTC