We Built 5 VS Code Extensions to Fix Our Own Workflow - Then Gave Them Away

None of our VS Code extensions started as a product idea. Every one of them started as a small, recurring annoyance that finally crossed the line from "I'll just deal with it" to "I'm fixing this properly."

The pattern behind all five

Running multiple local servers meant constantly switching to a terminal to find out what was hogging port 3000 - so we built Port Manager, a real-time, in-editor view of every active port with one-click process termination.

Checking how a page would actually look shared on LinkedIn or Google meant deploying it first, which is backwards - so we built Meta-Lens, which generates the real social preview cards, an SEO score, and an accessibility audit, entirely from localhost, with nothing leaving the machine.

Previewing a README or a spec doc and then needing to hand someone a PDF version meant a clunky export pipeline - so we built SwiftMark Preview, a clean Markdown previewer with one-click PDF export and nothing else to configure.

New team members kept relying on the mouse for things a shortcut would do in a fifth of the time, and "just memorize the shortcuts" is advice nobody follows without structure - so we built Shortcuts Trainer, which turns 90+ commands into timed practice quizzes instead of a cheat sheet nobody reopens.

And a recurring class of bug - a missing env var, one that's declared but unused, a `.env` that's quietly drifted from `.env.example` - kept costing us an afternoon each time, so we built Environment Doctor: deterministic .env validation, no AI inference, zero telemetry.

Why give them away instead of keeping them internal

Because the annoyance we were fixing isn't unique to us. Every developer running multiple local servers has the port problem. Every team shipping a public page cares how it previews on social. If a tool is genuinely useful enough that we'd be annoyed to lose it, it's probably useful to more people than just our own team - and publishing it costs us almost nothing once it's already built for internal use.

The honest test for whether an internal tool is worth publishing: would we be annoyed if we lost it? If yes, someone else probably needs it too.

All five are free, published to both Open VSX and the official VS Code Marketplace, and none of them phone home or require an account. That's not a generosity pose - it's the same reasoning behind the tools themselves: build the thing that removes the friction, and don't add friction back in on the way out the door.