I built a developer tool at 16, and it didn’t start as anything impressive or serious. It started simply because I was frustrated - which I didn’t even realise at first, as I just assumed it was all just part of programming.
Every time I opened a new codebase, especially anything larger than a school project, it felt like I was reading something that was barely understandable for most humans. Files depended on other files, functions called things that were buried deep in completely different folders, and I would be constantly jumping between tabs trying to properly visualise how everything worked together.
It wasn’t that I couldn’t understand the code. It was that it took way to long to understand what should be a simple task, and i felt like I was rebuilding a mental image of what the codebase looked like every time I reopened a project. After a while, I began to wonder: there has to be a better way to do this.
That’s where I got the idea to build CodeAtlas. I didn’t consider it to be a startup or even a project that I could share with other people at the time. It was more like a challenge I had set for myself: what if I could find a way to visualise a codebase instead of just seeing files and folders?
At the start, I built the simplest version I could have possibly thought of. It was just a script that scanned a repository, checked the import statements and tried to draw lines between files. No fancy interface, or real structure behind it, I was just trying to see if the idea made sense outside of my brain.
The first time it actually worked, even though it was messy and broken, it flt weirdly different from what I had built before. It felt useful, like something people would actually want to use.
But this version was far from useful. It constantly broke, especially on anything that was even slightly complex. Bigger projects took an eternity to load and created chaotic webs where everything overlapped and it was impossible to tell what was going on.
Still, instead of starting over, I continued to improve it, bit by bit. I worked on improving the accuracy of detection, I added features like search bars and code viewers, and over time, it began to feel more and more like something that could actually help people understand real-world codebases.
The turning point wasn’t when I added a new feature, or I finally got something to work. It was when I showed my project to someone else for the first time. I expected them to comment on the visuals of the graph, or how interesting it looked, but instead, they came back to me and said this had helped them onboard new developers to their codebases.
That moment stuck with me more than anything else whilst creating this project.
This was when I realised I wasn’t simply drawing lines between files, but I was helping people reduce the complexity of repositories into something more abstract that people can actually understand and hold in their mind.
After this moment, I started thinking about CodeAtlas differently.Every change I made form then on wasn’t about making it more visually appealing, it was about making understanding faster. I started rebuilding parts that didn’t scale properly. I change how relationships were displayed.
And like most projects that begin to get real, i eventually ran into the part that nobody talks about enough: it is easy to continue improving a project forever, but it is much harder to actually finish it.
I always had an ongoing list of features that I could add, and improvements that would make it feel slightly more complete. But I stopped waiting for it to feel finished and I uploaded it to GitHub. It wasn’t perfect, and it still isn’t. But people could use it, load real repositories and actually get something useful out of it.
Looking back now, what I built hasn’t just been a developer tool for visualising dependencies. It has changed how I see code entirely: I don’t just see files anymore, I see relationships, structure, and how it all connects together under the surface.
And, weirdly, CodeAtlas wasn’t just something that helps me to build repositories better. It taught me how to see code from a different perspective.
Thanks for reading.
I’m curious... what’s the most confusing part of a codebase for you when you join a new project?
Drop it in the comments. I’ll read through them and it might shape what I build next.
Try CodeAtlas → GitHub
More writing → Substack
Follow the build → X (Twitter)
Top comments (0)