tiny-helpers.dev is a catalogue of one-purpose web tools

The catalogue is the product, not the helpers

tiny-helpers.dev describes itself as a collection of useful online web development tools, and the package metadata calls them free single-purpose online tools for web developers. That framing is the whole idea. Each entry does one small job, opens in a browser, and leaves. There is nothing to install, no account to create and no configuration to carry between machines, which is the difference from a package of CLI utilities that has to be added to every project. The audience is the working developer who needs to convert a colour, format a snippet or inspect a payload right now, and who would rather open a URL than remember a command. The site is MIT licensed, the repository is public, and the last push was on 2026-10-12, so the catalogue is alive on the deployment side even though the project itself has stopped growing. The repository has no GitHub releases, and the version field in package.json still reads 1.0.0, which is a sign that the version tracks the site rather than a published package.

Helpers are Eleventy pages, not scripts you import

The repository layout explains how a helper is built. The site/ directory is the Eleventy input, and the build script runs eleventy --input=./site, while the dev script runs eleventy --serve. A separate helpers/ directory holds the helper content, lib/ holds shared library code, api/ holds the API routes, and scripts/ holds the Node scripts that the npm scripts call. The primary language of the repository is Nunjucks, the templating syntax Eleventy uses, which is the point: a helper is a page rendered from a template rather than a piece of code you import into a project. The npm scripts show the pipeline around that. A setup step runs node ./scripts/create-feeds.js, the build runs after setup, and a postbuild step runs node ./scripts/create-dump.js, which suggests a static dump of the catalogue is produced for consumption elsewhere. The dependency list reinforces the shape: puppeteer and puppeteer-core for rendering, jimp for image work, postcss with import, nested and clean for stylesheet processing, terser and html-minifier for output, slugify for URL slugs, got for fetching, feed for the feeds and inquirer for the interactive add-helper script.

npm run dev serves the site, but the root route stays empty

Running the project locally is a single command, and the README attaches one important caveat to it.

npm run dev

The project uses Vercel's routing configuration, and the / route does not work locally, so after starting the dev server you have to navigate to localhost:8080/home/ instead of the root address. That is the sort of detail that costs an afternoon the first time, and it is why this paragraph exists. The other scripts in package.json cover the rest of the lifecycle. A helper can be added with the helper:add script, which calls node ./scripts/add-helper.js and uses the inquirer dependency to ask questions interactively. The build reads from the site directory, the postbuild step writes a dump, and the deploy script builds and then publishes with now --prod, while the Checkly commands run the end-to-end checks against the deployment.

  "dev": "eleventy --serve",
  "build": "eleventy --input=./site",
  "deploy": "npm run build && now --prod",

The runtime requirement is stated in the package metadata.

  "engines": {
    "node": "^22"
  }

Contributions are closed, so the catalogue can only shrink

The README leads with a section titled contributions are closed, and it is worth reading in full because it changes what this repository is for. New helper suggestions are refused and pull requests are disabled, and the stated reason is that the project was flooded with low-effort, AI-generated submissions, whose review costs more than the maintainer wants to spend. The thanks to the people who contributed thoughtfully over the years is genuine, and the list of contributors that follows is long, covering developers working on Eleventy, front-end tooling and web performance. The practical consequence for an adopter is asymmetric. The catalogue of existing helpers stays useful and the deployment keeps working, but nothing new arrives, and the mechanism that used to grow it is deliberately shut. The project is also a good record of a common pattern, where a community contribution model is closed to a flood of low effort submissions and the answer is to freeze the collection rather than keep triaging it.

Checkly watches the deployed helpers for breakage

The repository keeps an eye on the live site rather than only on the build. A checkly.config.js sits at the top level, the @checkly/cli is a dev dependency, and the npm scripts expose checkly:test and checkly:deploy, the latter running npx checkly deploy --force. A Checkly badge in the README points at the check results, so the state of the deployed helpers is a visible, monitored thing rather than a matter of trust. The scripts directory also holds the add-helper and feed generation scripts, and there is a tests/ directory in the tree. The other configuration files in the repository describe the editor and the tooling: an .editorconfig, a .prettierrc and a .prettierignore, a .nvmrc pinning the Node version, an .npmrc, a .gitignore and an .eleventy.js that holds the Eleventy configuration. The .claude/ directory suggests the project is worked on with AI assistance in the same way the submissions it refuses are. The site is a Vercel deployment, with vercel.json in the tree and the routing behaviour that implies.

Using the hosted catalogue, or running your own copy

There is a real alternative to the hosted site, and it is your own deployment of the same codebase. Because the licence is MIT and the build is a plain Eleventy pipeline, a team can clone the repository, run the build and serve the result on its own infrastructure, which is the difference between borrowing a public service and owning a copy. That is not a hypothetical path either, since the deploy script targets a hosted platform and a fork can point it elsewhere. What you get in a fork is the current catalogue and the machinery to add helpers, because the helper:add script and the templates are in the tree even though upstream pull requests are closed. What you do not get is upstream's new helpers, and the site also mixes helpers with a fair amount of hand-written content, so a private instance is best understood as a starting point rather than a finished product. Between the two options, a developer who needs a tool once should use the hosted catalogue, and a team that wants the tools on their own domain and under their own control should fork and run the build themselves.

What the catalogue cannot do for a build pipeline

The limits of this project are structural and worth being blunt about. These are browser pages, so a script that wants to format a hundred files, transform a payload in CI or check a response header cannot call the catalogue and expect a result; the tools are for a human at a keyboard. The repository describes them as single-purpose and free, with no API product attached to the promise, and the api/ directory belongs to the site rather than to a documented public interface for the helpers themselves. Offline use is likewise absent, since the tools live at a URL. A developer who needs one of these jobs repeatedly, on many inputs, inside a project, is in the wrong place and should install a package for it instead. The catalogue is at its best exactly where it is thin: one job, one visit, no setup, and an answer on screen. Judging it as a platform rather than as a bookmark list will always come out badly, which is also why the frozen contribution model is less damaging than it first appears.

Editorial conclusion

Adopt tiny-helpers.dev as a bookmarked catalogue when you want a quick tool for a one-off job such as formatting a snippet, and fork it when a team needs its own instance, since the MIT licence and the Eleventy build allow that. Do not expect a library, a CLI or an API from it, and do not plan around new helpers arriving, because contributions are closed. Verify first that the helper you need exists today, that the site is reachable in your network, and that a local checkout gives you the helpers rather than only the listing, given that the / route does not work outside the Vercel deployment.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. stefanjudis/tiny-helpers on GitHub