So you went too far with Microservices
Microservices made sense at companies that already had the tooling to run them. Most teams copied the architecture and skipped that part. After a while only a handful of people still understand the whole system. Agents don't either. They're just as blind.
Microservices at smaller orgs
A pull request is sitting in someone's queue. Ask around and nobody can tell you which other services will break if it merges. That's usually when you start wondering: was introducing microservices worth it? Or was it mostly resume driven development?
Netflix and a few other large firms can run a lot of services because they already paid for the boring stuff. Monorepos, or builds that are actually fast. CI you trust. Alerting that someone looks at. Most teams copied the service boundaries and didn't copy any of that. Then a new hire, or an agent with no context, only ever sees one tiny slice. Hard to own a change when you can't see what it hits.
The 42% stat isn't in the report
You'll see this number going around: the 2025 CNCF survey found 42% of organizations pulling back from microservices into "modular monoliths." We opened the report instead of copying it from other blogs. It doesn't say that. It barely talks about microservices.
The fake stat is still pointing at something real. A lot of teams cut the system into too many pieces, inherited the operational cost, and are now gluing things back together. You don't need a survey for this. Look at a single service the way a new developer does on day three. You get a glimpse. The rest is a rumour.
The org chart and the service map drift apart
The pitch for microservices was independence. Small teams, separate deploys, fewer bottlenecks. Fine, while the people who built each service still own it.
Then the org reshuffles. A service that had a dedicated team now has rotating on-call and a README from 2022. The people who knew why the boundaries were drawn that way leave. New hires get code they didn't design. At some point the org chart and the actual dependencies don't look like each other anymore. Things still run, mostly. Nobody is quite sure what's coupled to what.
It's slow. One service, one team shuffle. Then the CTO leaves, and the next one inherits a system with no current map.
Reviews without a blast radius
With a handful of services a lead can still hold the system in their head. When that falls apart, reviews go two ways. Either nobody has the context to push back, so it becomes a rubber stamp. Or everything waits for the one person who still understands the blast radius.
That's how breaking changes ship. People still care. The review just has no way to see downstream effects.
Putting it all back in one repo doesn't fix understanding
Consolidating into a monolith is popular right now, and it does help. Searching is faster, compiling is faster, tests are easier to run. Understanding the system is not much easier. We still rely on docs and diagrams someone drew, and those go stale about a week later.
I wanted a map from what actually shipped: the code in git. Not a slide deck or an a Confluence page with an outdated diagram that was last edited by someone who left.
What we've built
As a CTO I needed a view of the systems and the people that didn't depend on someone updating a diagram. That's why I started Comper.
We read git. GitHub, GitLab, Bitbucket and even Azure DevOps. If you bought a company and they lived on another forge, same problem. One org, more than one history.
Line History is an incremental git blame. When a pull request comes in we can tell you who last touched the relevant lines, without re-blaming the whole repository.
We also flag low test coverage and outdated dependencies. We rank what we can see, but the beauty of code is that it shows you the actual truth. Our AI can often infer most of the architecture and its issues from it.
Ownership comes from contribution history. It drifts when people move, which is the point. The map should follow them, not sit in a spreadsheet.
For connections between systems we combine git analysis with agent inference. The useful bit is that an engineer or an agent can see likely downstream effects, instead of starting from a single repo.
Whether you're stuck with microservices or not, our context engine can you help you navigate your complex systems.
See it at getcomper.ai.
Questions
Find answers to common questions about Comper
Do you only work on microservices?
No. Doesn't matter if it's services or a monolith. If it's in git we can read it.
How do you keep the map current?
We fetch the repos and rebuild from git history, plus some scanning and agent inference. As current as the last sync. Not a live view of production.
How expensive is it?
We start at EUR 5.000 a year, or just 433 per month. You can check out the details on our pricing page or request a demo with our Co-Founder Juan to see if Comper is right for you.
