Most developer machines are not clean. They just look clean.

At some point, every dev laptop turns into a dumping ground. You install tools to follow a blog post. You try a framework for a weekend. You switch jobs and inherit a new stack. You uninstall things, but only halfway. Binaries stick around. Config files stay buried in your home directory. Caches grow quietly in the background.

Nothing is fully broken, but nothing feels right either.

Your terminal starts acting weird. A command points to a version you did not install. You run which python and do not like the answer. Node exists in multiple places and you are not sure which one is winning today. You tell yourself you will clean it up later.

Later never comes.

SnapPoint is built for that exact moment. The moment where you realize your system is out of alignment, but you do not trust yourself to fix it without breaking something.

What SnapPoint actually is

SnapPoint is not another package manager. It does not try to replace Homebrew, NPM, Pip, NVM, Cargo, or anything else you already use.

It sits above them.

SnapPoint is a system auditor and a package manager manager. Its job is to understand what is installed on your machine, where it came from, and whether it still belongs there.

Instead of blindly uninstalling things, SnapPoint builds a mental model of your system first. It scans global binaries. It traces their origins. It checks your PATH. It looks for conflicts, orphans, broken links, and leftovers.

Only after that does it let you take action.

That difference matters.

You are not guessing anymore. You are choosing.

The mess we all pretend is normal

Modern dev environments are layered. You have OS level tools. Language level tools. Project level tools. Then wrappers around those tools.

Each layer does its own cleanup. None of them coordinate.

Homebrew removes a package, but not always the config. NPM deletes a global package, but not the cache. Pip installs scripts into places you forget about. Manual installs from curl or GitHub releases often never get removed at all.

Over time, this creates a few common problems.

Ghost binaries sitting in /usr/local/bin or /opt/homebrew/bin that no manager claims anymore.

Multiple versions of the same tool competing for priority in your PATH.

Gigabytes of cache files for tools you have not used in months.

Orphaned dependencies that were installed for something you already removed.

These are not edge cases. This is the default state of most dev machines after a year or two.

SnapPoint is designed to surface all of that.

The Hunt: understanding before deleting

The first phase of SnapPoint is called the Hunt.

This is where it scans your system and builds an inventory. Every global binary it can find. Every path entry. Every manager it recognizes.

For each tool, SnapPoint tries to answer a simple question. Where did this come from?

Was it installed by Homebrew. NVM. Pip. Cargo. Or was it dropped there manually with no record.

That origin story is the key.

Once you know where a binary came from, you can decide what to do with it. Without that context, cleanup is just educated guessing.

SnapPoint turns that guesswork into visibility.

Ghosts and orphans

Some of the most useful output from SnapPoint is what it calls ghosts.

These are binaries that exist on your system but are not managed by anything anymore. No package manager claims them. No version manager tracks them. They are just there.

Ghosts are often harmless, until they are not.

They override commands. They confuse PATH resolution. They break scripts that expect a different version. And because no tool owns them, nothing ever removes them.

SnapPoint finds these ghosts and flags them clearly. It does not delete them automatically. It shows them to you and explains why they are suspicious.

The same goes for orphans.

Packages that were installed as dependencies and never cleaned up. Global tools that duplicate what a local project already manages. Broken symlinks pointing nowhere.

This is the stuff that slowly degrades a system. SnapPoint shines a light on it.

Aligning your PATH instead of fighting it

PATH issues are one of the most frustrating parts of local development.

You install a tool. It works. Later you install another version somewhere else. Suddenly the wrong one runs. You add another export to your shell config and hope it sticks.

SnapPoint approaches this differently.

When it detects multiple versions of the same tool, it shows them all. Where they live. Who installed them. Which one is currently active.

Then it lets you choose the source of truth.

Instead of endlessly tweaking PATH by hand, you make an explicit decision. This version wins. The others get demoted or removed.

That alignment alone can save hours of debugging over the lifetime of a machine.

Cleanup that actually cleans

Uninstalling is easy. Cleaning up is not.

Most uninstall commands only remove the binary or package reference. They leave behind config folders, state files, and caches. Over time, these leftovers cause strange behavior when you reinstall something later.

SnapPoint includes the idea of cleanup recipes.

A recipe describes how a tool should be fully removed. Not just the executable, but the related folders in .config, .cache, and other known locations.

This knowledge is shared and community driven. No single person knows where every tool hides its junk. That is why SnapPoint is open source.

If you have ever reinstalled a tool and wondered why it still remembered old settings, this is why. SnapPoint aims to fix that properly.

Doctor mode

Some problems are subtle.

Broken symlinks that point to versions that no longer exist. Global packages that shadow project local ones. Tools that are technically installed but unusable.

SnapPoint includes a doctor mode that looks for these issues and reports them clearly.

Not as cryptic warnings. As actionable information.

This is especially useful on machines that have gone through OS upgrades or major stack changes.

System profiles and Snapfiles

One of the longer term ideas behind SnapPoint is system profiles.

Instead of treating your machine setup as a one time thing, SnapPoint lets you export it.

Your tools. Their versions. Their sources. Your alignment choices.

This becomes a Snapfile or snap.json.

You can use it to recreate your environment on a new machine. You can share it with teammates. You can publish it as a curated setup.

Think less dotfiles magic and more explicit system DNA.

This makes onboarding faster and personal setups portable.

Who SnapPoint is for

SnapPoint is for developers who care about their tools but are tired of babysitting them.

It is for people who want to understand their machine, not fight it.

If you have ever been afraid to clean your system because you were not sure what would break, SnapPoint is for you.

If your laptop feels slower or stranger than it should, SnapPoint is for you.

If you want confidence instead of superstition, SnapPoint is for you.

It is still early. The roadmap includes a full TUI dashboard built with Go and Bubble Tea, smarter purging, and social system profiles. But the core idea is already solid.

SnapPoint does not promise a perfect machine.

It promises clarity.

And once you have that, fixing the rest becomes a lot easier.