I build small tools that do the thing a subscription was charging for.
They start the same way: something simple is behind a login or a plan tier, so I read the API documentation, find out the hard part takes about forty requests, and write the client myself. The results run on your machine, have no backend, and cost nothing to operate, because there is nothing to operate.
- tubescope · YouTube channel analytics and CSV export, as a Firefox extension. The paid tools charge $39 a month for the export button. TypeScript, 54 tests, submitted to addons.mozilla.org.
- hoard · An encrypted password vault in one file you can read before you trust it. Argon2id and ChaCha20-Poly1305, a documented vault format, a written threat model, 22 tests. Python, CLI and GTK.
- just-give-me-the-exe · Puts the download button back at the top of a GitHub repo, and says so plainly when a project has no release. JavaScript, no build step, written in an afternoon.
Everything is MIT and runs locally. No accounts, no servers, no telemetry.
I write things down. Every project here had a design document before it had code, and a README that is honest about the state it is in. "Early" and "unaudited" are useful words. Marketing is not.
I test the parts where being wrong is expensive. On the password manager that meant tamper detection and nonce reuse. On the extension it meant escaping strings that arrive from strangers. Both suites caught real bugs before anyone else saw them, which is the whole argument for writing them.
I would rather be corrected than agreed with. Review on these projects found a cross-site scripting hole, a message handler that could hang forever, and a bug that silently exported the wrong channel's data. All shipped fixed. None would have been found by me being confident.
I care most about the boring parts: what happens when the network fails, what the error message says, and whether the documentation tells you the truth about what the software cannot do.
If something here is broken, open an issue and be blunt about it.