Codebase Cartography contains tools that export any software project into single spreadsheets, so developers can chart source code folders into context-rich spreadsheet basemaps. Additional customized prompt generators, automations, and web-publishing utilities are also available.

How it helps

In software, small edits can have surprising ripple effects. Rename a function, move a file, or change what a function hands back, and code in a completely different corner of the project may stop working. Developers call the reach of those ripples a change’s “blast radius”, and measuring it before you start is one of the best ways to avoid breaking things.

The maps let you measure it with a few searches. Filter the Project Map’s Dependencies column for the file you plan to change to find every file that relies on it, check its complexity and test coverage, then follow the shared file path into the Feature Map and Content Map to see which features and on-screen text could be affected.

Example scenarios

• Renaming a shared helper. Before renaming a function used across the project, filter the Dependencies column for its file to list every file that uses it, so nothing gets missed.
• Upgrading a library. Planning to update an outside package? Search for it in the Dependencies column to see how many files use it and which features they power, then decide how much testing the upgrade needs.
• Retiring old code. If no other file lists a script as a dependency, it may be ready to retire. The maps give you evidence to check in the code before you delete anything.
• Changing a screen. Before rewording or removing a button, look it up in the Content Map to find the file that displays it and the features connected to it.

Example case study: a “quick fix” that stayed quick

A two-person team maintains an online booking site. A customer reports that dates appear in the wrong format, and the fix looks like a one-line change in a shared date-formatting file. Before touching it, one developer filters the Project Map’s Dependencies column for that file and finds nine other files that rely on it, including the invoice generator and the email reminders.

Instead of changing the shared function, they add a new option used only by the booking page, then check the Content Map for every screen that shows a date. The fix ships the same day, and invoices and reminders keep working exactly as before.

How it helps

AI (Artificial Intelligence) coding assistants are only as good as the context you give them. Paste in too little, and they guess. Paste in too much, and the important details get lost, answers slow down, and costs rise. Either way, you get more hallucinations: answers that sound confident but are wrong.

Your maps are a ready-made briefing. A few Project Map rows tell the assistant how the relevant files are built and what they depend on, Feature Map rows explain what the code is supposed to do, and Content Map rows show what people actually see. The assistant starts from the facts that matter instead of piecing them together from scattered snippets.

Example scenarios

• Understanding unfamiliar code. Paste the Project Map rows for a folder and ask the assistant to explain how its files work together.
• Fixing a bug. Share the rows for the files involved, including their dependencies, inputs, outputs, and error handling, so the suggested fix fits the code you really have.
• Adding a feature. Give the assistant the Feature Map rows for related features, so its suggestion follows the patterns your project already uses.
• Double-checking a suggestion. If the assistant mentions files or functions that don’t appear in your maps, ask it to check again before you accept anything.

Example case study: the assistant that stopped guessing

A freelance developer asks an AI assistant to add a “forgot password” feature to a client’s app. The first attempt, based on a few pasted files, invents a helper function that doesn’t exist and saves settings in the wrong place.

On the second try, the developer pastes the Project Map rows for the sign-in folder and the Feature Map rows for the existing sign-in features. The assistant now uses the project’s real functions and storage, and its plan lines up with the maps, which makes it much easier to review before any code changes.

How it helps

A prompt is the request you give an AI model, and the best prompts are specific: what you want, where it lives, and what must not break. Writing that context by hand every time is slow, and it’s easy to forget something important.

The maps hold that context in a compact, organized form, and Prompt Tools can assemble it for you. It combines your maps, a project profile, and your feature notes into a detailed prompt, ready to paste into the AI chat in your code editor. Spreadsheet rows usually take far fewer tokens (the small chunks of text AI tools read and often charge by) than whole files of code, so your prompts stay focused and affordable.

Example scenarios

• Starting a new task. Prepare a feature document with Prompt Tools, then load it as the behavior contract the assistant must follow.
• Planning before coding. Choose the Strategy / Planning role to ask for a plan first, before any code is written.
• Checking the work. Use the Verification / QA (Quality Assurance) role to have the assistant review a change against your maps and notes.
• One shared starting point. Share your project profile, a small .json file, so everyone on the team starts from the same description of the project.

Example case study: from vague request to clear brief

A product designer who writes a little code wants a new “export to PDF” button in an internal tool. Their first prompt, “add a PDF export button”, produces code that ignores the tool’s existing export features.

With Prompt Tools, they attach the three maps, describe the behavior they want in a feature document, and copy the prompt it prepares. This time, the assistant finds the existing export code, reuses it, and lists the files it plans to change, a plan the designer can check against the Feature Map before approving it.

How it helps

Documentation often falls behind because writing it by hand takes time, and code changes faster than anyone can keep up. Codebase Cartography gives you a head start: the maps describe every file, feature, and piece of on-screen text automatically, and you can refresh them whenever the code changes.

From there, add what only people know. The Feature Map has columns for plain-language names, descriptions, status, and notes, and your notes carry forward when you regenerate the maps from your saved template. Codebase Publisher can also turn the code itself into a readable, printable website, so the documentation and the code travel together.

Example scenarios

• A living feature list. Name your key features in the Feature Map and mark whether each one works, creating a status page anyone can read.
• A tour of the code. Publish the project with Codebase Publisher and share its index page as a browsable reference.
• A screen-by-screen guide. Filter the Content Map by file to list every button, label, and message on each screen.
• Release notes. Compare this month’s maps with last month’s to see which features and screens changed.

Example case study: documentation that finally kept up

A nonprofit’s volunteer developers maintain its donation website. Every few years someone writes documentation, and within months it’s out of date. This time, they export the three maps, spend an afternoon naming the 20 most important features and describing each in a sentence, and save the result as their Feature Map template.

Each month, they regenerate the maps. New files appear automatically, their notes carry forward, and the Status column highlights anything new or no longer detected. The documentation now keeps up with the code instead of falling behind.

How it helps

Problems in software commonly occur in the iterative process. Files quickly grow until they are difficult to interpret, complexity creeps up, new dependencies sneak in, or a label changes without anyone noticing. Each developmental step might seem harmless enough, but multiple development steps and cycles compound together which ultimately makes the code harder and riskier to work with. That gradual buildup is often called technical debt.

Because every export is a spreadsheet, you can keep dated snapshots (turn on timestamps in Output) and compare them side by side in your spreadsheet app. Sort by size, lines of code, or cyclomatic complexity (a score for how many different paths the code can take) to track the iterative process, and see what’s growing or changing. Use Diff software or AI agents to test for differences and changes that flag any concerns.

Example scenarios

• A daily health check. Export at the start of each session and sort by complexity to see which files are getting harder to maintain.
• Before and after a big change. Map the project before starting a new development cycle and again afterwards throughout the iterations to confirm that only the expected files changed.
• Watching on-screen text. Compare Content Maps between releases to catch wording that may have inadvertently changed by accident.
• Keeping dependencies in check. Look for new entries in the Dependencies column so no unexpected outside code slips in.

Example case study: the file that grew too big

A small software company compares its quarterly snapshots and notices that one file’s lines of code have more than doubled, while its complexity score keeps climbing. Nothing is broken yet, but most recent bugs have come from that corner of the app.

The team schedules time to split the file into smaller, simpler modules before the next big feature. The following snapshot confirms the result: several smaller files, each with a lower complexity score, and a part of the app that’s easier to test.

How it helps

Translating software (often called localization) and making it accessible to everyone both start with the same question: what text does the software show, and where does it come from? Answering it by clicking through every screen is slow, and it’s easy to miss messages that appear only in certain situations.

The Content Map answers it for interfaces built with web technologies: HTML, JavaScript, JSX, and TSX. It lists buttons, labels, headings, form fields, tooltips, and messages, together with the file and line each one comes from, when it appears, whether it’s already set up for translation, its locale key, and its ARIA (Accessible Rich Internet Applications) label, the hidden name that screen readers announce for icons and other controls.

Example scenarios

• Preparing a translation. Filter for text that isn’t localized yet to see exactly what needs setting up before translators can start.
• Checking screen-reader labels. Find icon buttons without an ARIA label, so people who use screen readers know what each one does.
• Consistent wording. Sort by text to spot the same action described in different ways, such as “Delete”, “Remove”, and “Discard”.
• Hidden messages. Filter by visibility and condition to review error and warning messages that rarely appear during testing.

Example case study: going global without the guesswork

A small team selling scheduling software wants to launch in Spanish and French. Instead of hunting through the app screen by screen, they export the Content Map and filter the Is Localized column. It reveals dozens of messages written directly into the code rather than stored in their translation files.

They fix those first, then send translators a clean list with locale keys and context for every piece of text. While they’re at it, they filter the Aria Label column and add missing labels to several icon-only buttons, making the app easier to use with a screen reader.

How it helps

The first weeks on a new project are often spent just figuring out where things are, and asking busy teammates the same questions every newcomer asks. It’s slow for the newcomer and distracting for everyone else.

The maps give newcomers a guided tour. The Project Map shows how the project is organized and which files do what, the Feature Map explains what the software can do, and the Content Map connects screens to the code behind them. Newcomers can explore at their own pace, in spreadsheet formats they already are familiar with working with.

Example scenarios

• A first-day reading list. Filter the Project Map to the most important folders and share it as a starting point.
• Self-guided exploration. Newcomers search the maps for a feature they’ll work on and trace it to its files.
• Fewer interruptions. “Where does this happen?” becomes a quick search instead of a message to a colleague.
• A confident first task. Pair a first assignment with the Feature Map rows it touches, so the newcomer knows where to start.

Example case study: summer interns, up and running

A university research lab welcomes three summer interns to help with its data-analysis software. In past years, the first two weeks went to explaining the code.

This year, the lab shares its maps, plus a Codebase Publisher website of the code, before the interns arrive. On day one, each intern traces their assigned feature from the Feature Map to its files and arrives at the first meeting with sharper, more specific questions. The staff spend their time mentoring instead of repeating the same tour.

How it helps

Sooner or later, most people who work with software take over code they didn’t write: a former colleague’s project, a system built by an outside agency, or a product that arrived with an acquisition. The original authors may be gone, the documentation may be thin, and you may not know which parts still matter.

A first scan gives you an honest inventory: every file and folder, the languages used, the biggest and most complex files, the outside code the project depends on, and any possible passwords or keys left in the code. Think of it as a home inspection before you start renovating.

Example scenarios

• A departing colleague. Map the project together before they leave, and use their last weeks to fill in the Feature Map’s notes.
• An agency-built system. Check what you received: which languages and libraries it uses, how complex it is, and whether any secrets were left in the code.
• An acquisition. Get a clear picture of a product’s code as part of due diligence, the fact-finding before a deal closes.
• Reviving an old project. Scan an old codebase to see what it depends on before deciding whether to update it or rebuild it.

Example case study: keeping the lights on

A family-owned shop relies on an online ordering system built years ago by a freelancer who has since moved on. When it needs a small change, the shop hires a new developer who has never seen the code.

Before changing anything, the developer runs a scan. The Summary shows the size and makeup of the project, the Project Map highlights a handful of very complex files at the heart of checkout, and the sensitive-data warning flags a payment key saved directly in a settings file. The developer moves the key somewhere safer, makes the requested change, and leaves the shop with maps for whoever comes next.

How it helps

When a project changes hands, the code alone rarely tells the whole story. Clients want to know what they paid for, and whoever maintains the project next needs to know how it fits together.

A handoff package can include the three maps, a Feature Map with plain-language names and notes, and a Codebase Publisher website of the code. It shows the client exactly what was delivered, gives the next developer a map instead of a maze, and makes your work look as professional as it is. Before sharing, keep Redact All on and review the export, so no passwords or keys leave with the files.

Example scenarios

• End-of-project delivery. Include the maps and a published code website with the final files.
• Milestone reviews. Share updated maps at each milestone to show progress in a format clients can open and read.
• Support contracts. Compare maps from month to month to show what changed during each support period.
• Preparing the next team. Hand over a Feature Map listing each feature, its status, and anything that still needs work.

Example case study: a handoff with no follow-up calls

A two-person design studio builds a booking app for a chain of fitness centers. At handover, along with the code, they deliver the three maps, a Feature Map describing each feature in plain words, and a Codebase Publisher website that the client’s IT (Information Technology) team can browse offline.

Months later, the client’s new in-house developer adds a feature using the maps as a guide, without needing to call the studio for help. When the client plans its next project, it hires the studio again.

How it helps

Audits and technical reviews start with the same request: show us what you have. Reviewers need to know which files exist, which outside code and services they rely on, and where sensitive information might be hiding. Assembling that by hand is slow and easy to get wrong.

Codebase Cartography produces that inventory as spreadsheets reviewers can sort, filter, and annotate. The Dependencies and API usage columns show outside code and services, the error handling and test coverage columns point to weak spots, and the sensitive-data scan lists possible passwords and keys, all without your code leaving your computer. The maps support a review rather than replace one: detection is based on patterns, and a person should always confirm what matters.

Example scenarios

• Security reviews. Start with the possible secrets and the files that call outside services, where problems often hide.
• Supplier code. Map code you received from a supplier to see what it’s made of before you rely on it.
• Audit preparation. Use the maps as part of the evidence you gather for internal or external audits.
• License checks. List the outside libraries a project depends on, so someone can confirm their licenses allow the way you use them.

Example case study: ready for the auditors

A small healthcare startup is preparing for its first security assessment, a requirement from a large hospital customer. The auditors ask for an overview of the codebase, the outside services it uses, and how secrets are handled.

The team exports the maps and reviews the sensitive-data findings, which point to two old configuration files holding real credentials. They remove the credentials, rotate (replace) the keys, and export clean maps with Redact All on. The auditors receive a clear, sortable inventory, and the review moves on to the questions that matter.

How it helps

Not everyone who cares about a software project reads code. Managers, clients, executives, and investors still need to understand how big a project is, what it can do, and how it’s progressing, and screenshots of code rarely help.

Almost everyone can open a spreadsheet. The app’s Summary section totals the files, folders, sizes, and file types at a glance, the Feature Map lists what the software does in plain language, and snapshots taken over time show progress. Anyone can sort, filter, or chart them in the spreadsheet app they already use.

Example scenarios

• Status updates. Share the Feature Map’s status columns to show which features work and which still need attention.
• Scoping new work. Use file counts and complexity scores to explain why one change takes a day and another takes weeks.
• Budget conversations. Show where the complicated parts are when discussing time and cost.
• Investor and board updates. Pair a simple chart of the project’s growth with the list of features delivered.

Example case study: the chart that settled a budget debate

A product manager at a shipping company is asked why a seemingly simple change to shipping labels will take three weeks. Instead of a technical explanation, they share a filtered Project Map: the label code touches files with some of the highest complexity scores in the project, and billing, tracking, and customer emails all depend on them.

A simple chart made from the spreadsheet shows those connections at a glance. Leadership approves the timeline and adds time for a cleanup, so future changes will be easier.

How it helps

Learning to code usually starts with small, tidy examples, but real software is large, messy, and connected in surprising ways. Stepping from one to the other is one of the hardest parts of learning.

Codebase Cartography turns real projects into something students can explore. They can see how files are organized, which functions each file defines, how information flows between parts, and how on-screen text connects to code. Terms like dependency, state, and cyclomatic complexity stop being abstract, because each one has its own column, and the column guide explains every one in plain language.

Example scenarios

• Exploring open-source projects. Map a well-known open-source project and have students trace one feature from the screen down to the code.
• Comparing designs. Map two projects that solve the same problem and discuss why they’re organized differently.
• Feedback on assignments. Map student projects to find very complex files or missing error handling worth discussing.
• Self-study. Map projects you admire to study how experienced developers structure their work.

Example case study: a classroom with a real codebase

A university professor or high school teacher wants students to practice working with real software examples, not just dry textbook exercises. Each student maps a small open-source web app and answers questions using the maps. Encouraged questioning might include: Which file instantiates the game character? What other files does it depend on? Which function is the most complex, and why?

Students can then make a small change and map the project again to see what moved. By the end of the unit, they can find their way around an unfamiliar codebase, a skill employers value highly.

How it helps

Games are some of the most complex software around: gameplay scripts, engine code, editor tools, shaders, build scripts, and thousands of asset files, often changing daily as the game is tuned. Keeping track of how it all connects is hard, especially on small teams where everyone wears several hats.

Codebase Cartography maps the code side of a game, including C# (used by Unity and by Godot’s .NET version), C++ (used by Unreal Engine and many custom engines), Lua (a popular scripting language for games and mods), Java, JavaScript, TypeScript, and Rust. You see which scripts depend on which, where the complicated gameplay logic lives, and how data moves between systems such as input, saving, and scoring. Other text files, such as shaders and settings, still appear in the Project Map with their type, size, and location.

Example scenarios

• Taming a growing codebase. Sort gameplay scripts by complexity to find “god objects”, scripts that try to do far too much, before they slow the team down.
• Finding what breaks what. Before changing the player controller, filter the Dependencies column to see every script that relies on it.
• After a game jam. Map a jam prototype to decide which parts are worth keeping for a full game.
• Modding and tools. Give modders or tool programmers a map of the scripts they’re meant to work with.

Example case study: a patch without surprises

A three-person indie studio has just launched its game, and players are reporting a save-game bug. The save system was written in a rush before launch by a developer who has since left.

The team maps the project and filters the Dependencies column for the save manager script: fourteen scripts rely on it, from the inventory to the achievements. The State mutation and Side effects columns show which of them change saved data directly. With the full picture, they fix the bug in one place, test the connected systems, and ship the patch without breaking anything else.

How it helps

Technical artists and production artists work where art meets code. They write the scripts and tools that move artwork through a production (often called the pipeline), keep naming and folder conventions in order, and make sure thousands of files end up in the right place, in the right format, at the right size.

Codebase Cartography maps that behind-the-scenes code, such as Python scripts and add-ons for Blender, Maya, Houdini, or Nuke, C# editor tools for Unity, C++ plug-ins, and JavaScript automation for design apps, showing what each tool does, what it depends on, and what it reads and writes. It can also inventory the project itself: turn off Ignore binary files to list images, models, and other assets with their type, size, and location. Files over 20 MB are skipped, but the Summary still lists each one, so oversized files are easy to find.

Example scenarios

• Documenting a pipeline. Map the studio’s tool scripts so artists and programmers can see what each tool does and which files it touches.
• Asset audits. Include image and model files in a scan, then sort by size to find oversized textures or stray files before a deadline.
• Naming conventions. Sort the Project Map by folder and file name to spot files that don’t follow the studio’s naming rules.
• Handing off tools. When a technical artist moves to another project, their scripts come with a map, not just a folder.

Example case study: the project that got heavier every week

A small animation studio’s project keeps getting slower to open, sync, and back up, and nobody knows why. A production artist scans it with Ignore binary files turned off. The Project Map lists every image and model with its size, and the Summary’s Skipped / Excluded Files list names every file over 20 MB.

It turns out that dozens of textures were exported far larger than the shots need, and old test renders are buried in the delivery folders. After a cleanup, the project is much lighter, and the team adds a monthly scan to its checklist so the problem doesn’t creep back.

How it helps

Modern audio work often involves code: game scripts that trigger sounds and music, whether produced by Digital Audio Workstations (DAWs) like Pro Tools or Logic Pro, or by spatial and dynamic sound hardware such as Wwise (Wave Works Interactive Sound Engine), or FMOD (Firelight MOD), the audio tools are connected to game engines, plug-ins and effects written in C++ or Rust, and Python scripts that batch-process thousands of files. When a sound plays at the wrong moment, or not at all, the answer is usually somewhere in that code.

Codebase Cartography helps you find it. Search the maps for your audio system’s name or a sound event to find every script that uses it, then check each file’s dependencies, functions, and data flow to see what triggers the sound and under which conditions. With Ignore binary files turned off, you can also inventory audio files under 20 MB to review their formats, sizes, and folders.

Example scenarios

• Tracking down a missing sound. Search for the function or event that plays a sound, then check which scripts call it and when.
• Reviewing plug-in code. Map a C++ or Rust audio plug-in project to see its structure, its most complex parts, and where audio processing happens.
• Batch-processing tools. Document the Python scripts that convert, normalize, or rename audio files, so others can run them safely.
• Organizing a sound library. Inventory a library’s folders, formats, and sizes to spot likely duplicates or files in the wrong format.

Example case study: the footsteps that went silent

A game’s footstep sounds stop playing on one level, but only sometimes. The sound designer suspects the audio system; the programmers suspect the level. Together, they map the project and search for the footstep event.

The maps show three different scripts that can trigger footsteps, and one of them checks the type of ground before choosing a sound. A new floor material on that level was never added to its list, so footsteps stayed silent there. With the right script in hand, the fix takes minutes.

How it helps

Making physical things increasingly runs on code: printer and machine firmware, scripts that slice, queue, and monitor jobs, parametric CAD (Computer-Aided Design) models written as code, test rigs, and analysis of engineering results. That code is often written quickly by makers and engineers who are experts in their field rather than in software, and it can be hard for anyone else to pick up.

Codebase Cartography maps it in plain terms. It analyzes C and C++ firmware, Python tools such as OctoPrint plug-ins, Klipper extensions, and CAD-as-code scripts, and the Julia or Rust used for engineering calculations. Settings and job files, such as JSON and INI profiles, OpenSCAD models, and G-code (the step-by-step instructions a 3D printer or CNC (Computer Numerical Control) machine follows), appear in the Project Map with their type, size, and location, as long as each is under 20 MB.

Example scenarios

• Customizing firmware. Before changing a printer’s firmware, map the project to see which files your change will affect.
• Running a print farm. Document the scripts that queue jobs, monitor printers, and report failures, so anyone on the team can maintain them.
• Parametric part libraries. Map a library of CAD-as-code parts to see which models depend on shared measurements or helper functions.
• Engineering test data. Keep the scripts that analyze test results documented, so results can be reproduced and checked later.

Example case study: a print farm that outgrew its scripts

A small product company prints customer orders on a farm of twenty 3D printers. Over three years, one engineer wrote dozens of Python scripts to queue jobs, check filament, and send alerts. When that engineer moves to a new role, nobody else knows how the system fits together.

Before the handover, they map the project together. The Project Map shows which scripts depend on the printer-control library, the Feature Map gets plain-language names like “low filament alert”, and the sensitive-data warning flags an email password saved in a settings file, which they move somewhere safer. The new owner starts with a clear map instead of a mystery.