Over a year ago, I didn’t know what a dotfile was.
I grew up on Windows. No opinions about editors, no .config folder I cared about. Then I installed WSL to poke at Linux and fell down the Ubuntu rabbit hole: Ghostty, then tmux, then vim. I stopped reaching for the mouse. Eventually I bought a Mac for the real Unix underneath, not a subsystem bolted onto an OS that fights you at every turn.
Once you start shaping your tools instead of just using them, you notice the gaps. For me, the gap was dead code.
The itch
I kept shipping code with loose ends. An exported function nobody imported. A type that outlived its last use. A circular dependency quietly forming between two modules.
None of it broke the build. All of it added up.
There are tools that find this stuff, but they live in a terminal, in a separate window, a context switch away from where I actually work. I wanted the answers in the editor, in a split, next to the code they were about.
So I built vallow.nvim.[1]
It brings static analysis straight into Neovim[2]: unused exports, dead code, circular deps, duplicate exports, complexity hotspots, all in a native split. Under the hood it’s powered by fallow, a Rust analysis engine that does the heavy lifting.[3] The plugin itself is Lua, and it’s deliberately unfussy: no LSP, no tree-sitter, no config to get started.
That screenshot is vallow running on the codebase for this site. It’s flagging the exact loose ends I’d let pile up: three helper scripts nothing imports, a component I’d built and never wired in, and a data file where 80% of the exports were dead.
The constraint I’m proudest of is the “no config” part. Every tool in this space eventually grows a settings file that becomes its own small project to maintain. I wanted the opposite: a thing you install and forget.
The part I didn’t plan for
I built vallow for myself. That was the whole scope. I had the itch, I scratched it, I used it every day.
Then I did the one thing that turned a personal tool into something more: I put it online. MIT licensed, open for contributions, a README that explained what it was for.
Not because I had a grand plan. Just because shipping felt like the honest end of building.
That’s what got me into Claude for Open Source.
I’m still a little stunned by the math: six months of the best tools I’ve used, for a plugin I made on evenings and weekends. It cost me a lot of Lua I had to learn as I went. The return was a door I didn’t know existed.
Dogfooding, all the way down
Here’s the part that makes me grin.
fallow, the engine behind vallow, has been running on this site the whole time. It’s how I found a sound-effect module I’d duplicated across two files, a dependency my icon script relied on by accident, and a 190-line button I’d copy-pasted instead of turning into a component.
The tool I built to keep my code honest keeps this code honest too. Build a thing, use the thing, let the thing improve the next thing. That loop is the whole reason any of this is worth doing.
The only advice I have
If you’ve been sitting on a side project, even one you’re sure nobody else wants, ship it anyway. Push the repo. Write the README. Add the license.
Open source rewards you in ways you don’t expect.
I expected to keep a plugin for an audience of one. What I got instead was proof that shipping the small things is worth it, and a reason to keep building in the open.