An API contract changes, a service wrapper needs an update, a test starts failing, or a database interaction quietly becomes inconsistent. Large companies often have internal tooling for this. University project teams and small development teams usually do not.

That is why I built Where am I: an open-source, local-first impact graph for tracing code changes across repositories.

The problem I wanted to solve

When several people work across multiple repositories, answering a simple question can take a surprising amount of time:

What could this change affect?

Developers may need to search API paths, inspect handlers, check wrappers, compare schemas, find related tests, and ask teammates for context. The problem becomes even harder for someone joining an unfamiliar codebase.

Where am I brings those relationships into one place and keeps the evidence connected to the relevant files and lines.

What Where am I can do today

The current version can:

• visualize code paths affected by the current working-tree diff;
• surface brief API and schema changes from teammates' pull requests and remote commits;
• connect API paths, handlers, wrappers, OpenAPI documents, and tests;
• search a combined API catalog across multiple repositories;
• trace functions, databases, external APIs, and error codes back to files and evidence lines;
• provide repository structure and system summaries for onboarding.

The goal is not to replace code review. It is to give reviewers and developers a clearer starting point, backed by traceable evidence.

Why local-first matters

Source repositories may contain internal endpoints, credentials, business logic, local paths, or other sensitive information. Requiring teams to upload all of that code to an external service creates unnecessary friction and risk.

Where am I analyzes repositories locally. Your code stays on your machine by default.

Generated snapshots can still contain project details, so they should always be reviewed before sharing. The local-first workflow simply makes privacy the starting point instead of an afterthought.

Who I am building it for

I especially want Where am I to be useful for:

• university and student project teams;
• small product and development teams;
• open-source maintainers and contributors;
• developers onboarding to an unfamiliar system;
• anyone coordinating changes across multiple repositories.

You should not need a dedicated platform team to understand how a change moves through your system.

What I am developing next

I want the roadmap to be shaped by real feedback rather than assumptions.

First, I am developing LLM-powered summaries of code changes. The goal is to turn collected impact evidence into a concise explanation that a teammate can review quickly, while still keeping the underlying file and line references available.

Second, I am working on a way to detect and explain changes directly from local working files, even when a project is not using Git. This should make the tool useful for lightweight prototypes, early-stage projects, classroom work, and other workflows that do not yet have a consistent Git history.

I also want to keep improving impact accuracy, repository integrations, onboarding workflows, and multilingual support.

I would like your feedback

If you work in a university team, a small development team, or a multi-repository environment, I would love to hear where change tracking becomes difficult for you.

Try the project and tell me:

• Which relationships are the hardest to trace?
• What information would make a pull request easier to review?
• Would an LLM-generated summary help, and what evidence should it include?
• How should the tool behave when Git is unavailable?

Bug reports, feature requests, and implementation ideas are all welcome as GitHub issues. If you are interested in testing, using, or contributing to the project, feel free to contact me.

• Open the live demo
• View the source on GitHub
• Join the project discussion

Where am I is licensed under the MIT License.