WHY PREBASE
The system is already in the code. Most environments never show it.
A large codebase is not a pile of files. It is a set of relationships that already exist, whether or not the editor surfaces them. PreBase started from that gap: between where code lives, and how the system actually works.
01
The file is not the system.
File trees are good at showing where code lives. They are much less useful at showing the structure those files create: the calls, types, ownership, and history that make a codebase a system rather than a directory.
02
Understanding should not be reconstruction.
As repositories grow, more of the work becomes recovering relationships that already exist in the code. That reconstruction happens in every new clone, every new teammate, and every return to an unfamiliar area. The cost is paid again and again because the environment never kept the structure in view.
03
Software now has two audiences.
People still have to find their way through the system. Agents now have to as well, at a different scale and with less intuition. An agent that sees files and snippets still has to guess how the whole fits together. Missing context is no longer only a navigation problem. It is a reliability problem.
04
Context belongs in the development environment.
Maps, history, and the work itself should not live in separate tools the developer has to assemble. The structure of a codebase should be something you can see and move through, in the same place you write and run the code.
05
That is what we are building.
PreBase exists to make that structure ordinary: present in the environment, available to the person at the keyboard, and usable by the tools working alongside them.
The product page is the work itself. This page is why that work needs to exist.