Earn the interruption.
A tool should solve a concrete problem clearly enough that keeping it is the easy decision.
About / howmanysmall
I build the systems that make other work easier to trust.
I'm an independent engineer and open-source creator. I build developer tooling, libraries, and the plumbing around shipping software. The goal isn't more machinery. It's fewer avoidable surprises.
The work
Useful software, without the ceremony.
Most of my work lives one layer below the product: lint rules, repository automation, lifecycle utilities, data structures, package tooling, and the connective systems that make a codebase easier to operate.
I care about performance because people avoid slow tools. Reliability matters because 'clever' failure modes are still failures. Documentation is the same: the public API starts the moment someone decides whether to use the tool.
I can and do build game-development systems, especially in the Roblox and Luau ecosystems. The broader throughline is platform and tooling engineering: turning repeated friction into a small, dependable system.
Operating principles
Standards that have to survive contact with a repository.
Stay inside the feedback loop.
Checks are most valuable while the change is still in working memory, not several tabs later.
Prefer boring failure modes.
Predictable behavior and useful diagnostics beat an abstraction that only looks elegant when it works.
Documentation is interface design.
People should be able to evaluate a tool without reverse-engineering the maintainer's assumptions.
Current threads
What has my attention now.
- Strict tooling
Porting and refining lint rules so the diagnostics remain specific, fast, and worth acting on.
- Repository automation
Removing the setup steps that otherwise survive as sentences somebody is expected to remember.
- Small public APIs
Revisiting utilities across TypeScript, Rust, Lua, and typed Luau to keep their boundaries honest.
Selectively open