freeStuffDev is a curated directory, and its admission rules are stricter than its welcome

Three rules decide what gets in, and one of them is a paywall flag

The site describes itself as a list of free services for developers, covering database, hosting, authentication and other categories, built to help someone start prototyping or building an MVP. The admission rules are short and unusual enough to be worth quoting.

Rule one: free stuff or a free trial of at least one year is accepted. That is a year, not a month, which rules out most credit card freebies.

Rule two is the interesting one: if a tool only offers a seven day trial, or has no free offer at all, mark it as `isPaid: true` in the frontmatter. So the site does not delete paid tools, it labels them. That is why a directory titled as free stuff can contain entries you have to pay for, and it is why the frontmatter field matters to anyone consuming the data.

Rule three is a list of exclusions, and it is a statement about what kind of resource this site considers useful. Language and framework specific tools are not accepted. Neither are links to a part of a specific tool, with the example given being themes for Hugo. Neither are libraries for a particular framework or language, with a JavaScript library named as an example. Neither are links to the documentation or a forum of a particular tool.

The stated reason is that those are great resources but there are more suitable places for them. In practice that means freestuff.dev is a directory of services rather than a link aggregator, which is why searching it for a JavaScript library returns nothing and should.

The categories are broad enough that the exclusion rules make sense: hosting, database and authentication are decisions you make once and are not tied to your language, while a library is chosen for reasons that have nothing to do with whether it costs money.

Every entry is a Markdown file in an Astro content collection

The data model is the simplest thing a static site generator can use, and it is also the whole contribution interface.

Entries live in `src/content/tools`, one Markdown file per service with a `.md` extension. The README shows a content template and separately requires an `isPaid` field in some cases:

---
title: "Your service name"
link: "https://link.to.service"
thumbnail: "https://any.logo.of/service"
snippet: "Service description, which will be shown under service name"
tags: ["Tag1","Tag2","TagN"]
createdAt: 2021-06-21T18:55:27+03:00
---
free feature 1
free feature 2
free feature 3

Six frontmatter fields and a body. The body is the list of free features, one per line, which means the free tier is enumerated rather than paraphrased. That is the most useful field on the site, since knowing a service exists is less useful than knowing exactly what you get for nothing.

Two of the fields have operational detail attached. Thumbnails can be any image, but the guidance is to avoid small favicons at 16 by 16, because every image is resized to 80 by 80. So the smallest sensible source image is around 80 pixels square, and the site states that resize as a fact rather than as a preference.

The tags field feeds the filtering UI. The instructions say that for existing tags you visit freestuff.dev and open the Filter, which is a nice constraint: reuse the existing vocabulary rather than inventing near synonyms that fragment the taxonomy.

`createdAt` carries a full ISO timestamp with a timezone offset in the example, not a bare date. That suggests the entries are ordered or displayed by date somewhere, though the README does not say how it is used.

Note what is absent from the schema: no rating, no pricing field beyond `isPaid`, no category field separate from tags, and no link to a documentation page. The design pushes every description into the snippet and the body.

A form that pre-fills a pull request, or a file by hand

There are two contribution paths, and the automated one is unusual.

The first is a form at freestuff.dev/submit. The README describes what it does: it will prefill some value for your GitHub pull request. So the submission flow is not a contact form and not an issue; it generates the content of a pull request, which keeps the site's data in version control with no server side write path.

The second path is manual and is spelled out step by step. Fork the repository, navigate in your fork to `src/content/tools`, create a new file for the service with a `.md` extension, and use the template above for the content.

Three details in the instructions reveal how much friction the maintainer expects. The filename guidance gives a concrete example name, `myservice.md`, which suggests files are named for the service. The extension requirement is stated explicitly, which suggests the build fails or the entry is ignored without it. And the closing notes repeat the body format, one feature per line, which is the format most contributors get wrong.

That the rules are repeated in the README, in the form, and implicitly in the template is a sign the author expects a rejection rate. The topic tags include `first-contributions`, `first-timers-friendly`, `good-first-issue` and `hacktoberfest`, so the project explicitly invites newcomers, and the rules are what make that workable.

Two features round out the site's shape. There is a submit route in the Astro app rather than a link to an external service, and a sponsor section listing Codehooks.io, described as a way to build and deploy flexible APIs with an integrated database in minutes. The sponsor link carries a referral parameter, which is how the site pays for its hosting.

Astro with Tailwind, Yarn 1, and an unusual ignore script

The technical stack is small and conventional for a content site, with one entry that does not belong.

`package.json` names the package `freestuffdev` at version 0.0.1, declares `type: module` and pins `packageManager` to `[email protected]`. Dependencies are Astro itself at `^4.3.2`, `@astrojs/tailwind` at `^5.1.0`, `tailwindcss` at `^3.4.1`, `sass` at `^1.70.0`, `typescript` at `^5.3.3` and `@astrojs/check` at `^0.4.1`. Configuration is split across `astro.config.mjs` and `tailwind.config.mjs`, with `tsconfig.json` alongside and a `yarn.lock` at the root.

The scripts are the standard Astro four: `dev` and `start` both run `astro dev`, `build` runs `astro check && astro build`, and `preview` runs `astro preview`. Running the type check inside `build` is the one deliberate choice, and it means a content typo that produces a type error fails the deploy rather than shipping.

The interesting file is `ignore-build.sh` at the root. A static site generator does not normally need a shell script at the repository root, and the README never mentions it. Its purpose is not documented anywhere in what is available here, so if you fork this project, read that script before you trust your build.

The rest of the tree is standard: `public/` for static assets, `src/` for the application and content, a `.vscode/` directory, and a `.gitignore`.

On maintenance and licence: the repository is not archived, the last push was on 2026-09-13, and there are no GitHub releases. The README states MIT License, while GitHub's own licence field shows as unclassified, so the same caveat as with several other directories applies. There is no changelog, which is consistent with a site whose content changes are the commits themselves.

Editorial conclusion

Use freeStuffDev when you are choosing infrastructure for a prototype and want a shortlist of options that were free when someone else checked, and treat every listing as a starting point rather than a verification. Do not submit framework specific tools, documentation links or single language libraries, since the contribution rules exclude them. Verify first the pricing tier of anything you plan to depend on.

Frequently asked questions

Official sources

1. hilmanski/freeStuffDev on GitHub
2. Issues
3. Project website
4. README