What I learned building developer tools

Most small developer tools get built in an afternoon, work for their original purpose, and quietly stop being maintained a week later. A few keep getting used past that point, by other people, not just their original author. The difference between those two outcomes has very little to do with how technically impressive the tool is.

What makes a tool worth keeping open

A tool that solves a problem only its author has, in a way only its author understands, tends to close after a day — it did its job, and there's no reason to return to it. What keeps a tool open is whether it solves something recurring enough that coming back to it is worth more than rebuilding the workaround from scratch each time. Coding Session Tracker started from exactly that kind of recurring, personal annoyance — wanting a lightweight way to see actual coding time inside the editor, without switching to a separate app — and it stayed useful specifically because that need didn't go away after the first use; it came back every day.

Building inside the editor's model, not against it

The VS Code Extension API is opinionated about how an extension is supposed to behave — where UI elements live, how state persists across sessions, how an extension should integrate with the command palette and status bar. The instinct, coming from web development, is to want more control than that model gives you. Fighting it — trying to build something that looks and behaves like a standalone web app bolted onto the editor — produces an extension that feels foreign inside VS Code, slow to build, and awkward to maintain against an API surface it's working against instead of with. Building with the grain of the extension model instead — a status bar item instead of a custom webview where a status bar item would do, the command palette instead of a custom command UI — costs less code and feels native, because it's using exactly the affordances VS Code already built for this purpose, instead of recreating them worse from scratch.

What packaging as a desktop app actually takes

Electron App Maker exists because packaging a web app as a distributable desktop app is a real, repeated piece of work every time you do it — not because Electron itself is complicated, but because there's a template of decisions that has to be made the same way every single time: auto-update configuration, platform-specific build targets, icon and installer metadata, code signing setup. None of these individually are hard. Doing all of them correctly, from scratch, for every new project that needs a desktop build, is exactly the kind of repeated setup work worth turning into a tool instead of redoing by hand each time — which is the actual reason a template-driven packaging tool is worth building at all, rather than just running electron-builder fresh on every project.

Built for yourself vs. built to hand off

The most concrete lesson across both tools: a tool built purely for yourself can carry undocumented assumptions, because you already know them — you know which config file to edit, which step to do manually before running it, which error message to ignore. A tool meant for someone else can't lean on any of that. Every assumption that lived only in your head has to either become a documented step or get removed from the tool entirely, because a stranger hitting an undocumented assumption doesn't push through it — they just stop using the tool at that exact point and don't come back to it. That gap between "works for me" and "works for someone who isn't me" turned out to be most of the actual engineering effort in both projects, and almost none of it was about the core feature either tool was originally built to do.