devFind: a directory of developers built from JSON files

A profile is a JSON file in a folder

devFind aims to create a platform where developers can present their skills and connect with potential collaborators, in a user-friendly and searchable format.

The mechanism is what makes it interesting. Developers create their profiles in JSON format, and those are then displayed on the web for others to discover. The profiles live in the public/data directory of the repository, one file per person, named after the GitHub username. There is no database, no signup flow and no account to create. The data is the git history.

The consequences follow from that choice.

For a contributor, adding a profile is a five step process that starts with forking the repository and ends with a pull request. For an operator, the deployment is a static Next.js site with a data directory, and there is no backend to secure, no user table to protect and no password reset flow to build. The trade is that every change to the directory, including adding a person, goes through code review, and removing a profile is a pull request that deletes a file.

That is the right trade for a community directory and the wrong one for a product that needs instant signup, private profiles, moderation queues or analytics on individual visitors. It is worth knowing which of those two things you are building before you fork it.

The project is a JavaScript and React application on Next.js, licensed MIT, with the live site at dev-find.vercel.app and the source in the repository.

Search by skill, location or name

The one key feature the readme names is the search, and it is worth being precise about what that means here.

Users can search for developers based on specific skills, locations or name. The readme then names the audience this serves: project managers, recruiters, and anyone looking to connect with skilled developers for collaboration or employment opportunities.

So the search is a filter over a flat list of JSON objects, and the fields it filters on are the ones the profile schema defines. The schema, from the readme's template, is short:

   {
     "name": "Your Name",
     "location": "Your Location",
     "bio": "Your Bio should be 20-30 words not more then that",
     "avatar": "https://github.com/<your-github-username>.png",
     "portfolio": "Your Portfolio URL or Github URL",
     "skills": ["Your Skill 1", "Your Skill 2", "..."],
     "social": {
       "GitHub": "https://github.com/<github-username>",
       "Twitter": "https://twitter.com/<twitter-username>",
       "LinkedIn": "https://www.linkedin.com/in/<linkedin-username>"
     }
   }

The skills array is the field that makes the search useful, because it is a list rather than a free text field, so filtering on a skill is a membership test rather than a substring match against a bio. The bio has a stated length expectation of twenty to thirty words, which is a small editorial rule that keeps the cards readable and keeps people from writing a CV into a card.

The avatar defaults to the GitHub profile picture URL pattern, which means most contributors get an avatar without uploading anything, and the social block is a keyed map of platform name to URL, which is what lets the card render links without hardcoding a fixed set of platforms into the component.

The contribution flow, step by step

The readme spends most of its length on the contributor path, and the flow is the thing a potential user should evaluate.

The prerequisites are a GitHub account, Git installed locally, and npm installed locally. The readme then explains how to install Git by downloading it from the official site and verifying with:

   git --version

For Node.js and npm, the instructions are to download the installer from the official Node.js website, choose either the LTS version for stable releases or the newest version, and then verify the install. Two commands confirm it:

     node -v

     npm -v

npm ships bundled with Node.js, so verifying Node verifies npm as well, and the readme adds an optional step to update npm to the latest version globally with:

     npm install -g npm@latest

Then the actual contribution. You fork the repository, clone your fork, and install the dependencies:

   git clone https://github.com/<your-github-username>/devFind.git

   npm install

After that you go to the public/data folder, create a JSON file named after your GitHub username, paste in the profile object with your own values, save it, and the readme continues to a step that goes to the components directory, which is where the site code lives.

The readme frames this as a contribution to an open source project, and the repository reflects that. The topics include good-first-issue and add-data, which is how a directory project solicits contributions, and there is a CONTRIBUTING.md and a CODE_OF_CONDUCT.md at the root. The contributors and support sections are the standard open source scaffolding, and the whole flow is designed so that someone can add themselves with no development experience beyond installing two tools.

A Next.js app with Tailwind and almost no dependencies

The application stack is small, and the package manifest shows exactly how small.

The scripts are the four you would expect from Next.js: dev runs next dev, build runs next build, start runs next start, and lint runs next lint. The package is private and marked version 0.1.0, which is consistent with a repository whose version number is not published as a library but is the version of the site itself.

The dependencies are next at 14.2.1 with react and react-dom at 18, tailwindcss at 3.4.15 with postcss and autoprefixer as the PostCSS side, and FontAwesome for icons in two forms, the SVG core with the solid icon set and the React component wrapper. There is also react-icons, which gives access to a wider icon set, and that is the whole runtime list.

The devDependencies add eslint at 8 with eslint-config-next at 14.2.1, matching the Next.js version, and there is an .eslintrc.json at the root.

The repository layout is the standard Next.js pages router structure rather than the app directory. There is a pages directory, a components directory, a public directory, a styles directory, a next.config.mjs and a postcss.config.mjs with a tailwind.config.js. A jsconfig.json is present for editor path resolution, and the package-lock.json means npm rather than pnpm or yarn is the expected toolchain, which matches the contributor instructions that tell people to use npm.

The topics listed for the repository include nextjs, react, tailwindcss, javascript, css and vscode, and also gssoc24, which points to the origin. This was a Girl Script Summer of Code project, and the shape of the readme, with its long explanation of how to install Git and Node.js for first-time contributors, is the shape of a project that was explicitly designed to be approachable by people who had never opened a terminal before.

The project state, and the question of what it is for

The dates are worth reading carefully, because they change what kind of project this is.

The releases are v4.0.0 from 2024-02-01, v3.0.0 from 2023-10-08 and v2.5.0 from 2023-07-03, so the version history shows a project that moved quickly through majors during its active period. The last push was on 2026-05-07, which is more than five months before today and well over a year after the last tagged release. The default branch is master and the homepage is the deployed Vercel site.

So this is a completed student project that continues to accept profile submissions, rather than a platform with an active development roadmap. Nothing in the readme promises ongoing work, and the feature list is a single search capability rather than a growing set.

That is a fair read, and it is also why the project is worth understanding as a pattern rather than a product. The design decision worth stealing is the data model: a directory of people as a directory of files in a git repository, with a pull request as the signup flow and the git history as the audit log. Every entry has a timestamp and an author, changes are reviewable, and a fork is a complete copy of the directory that someone can host themselves.

If you want to run a community directory, this is a working, readable implementation to start from, with the search, the card rendering and the schema already decided. If you want a professional hiring product, you need a database, an account system and moderation, and none of that is here.

The data directory being public and the site being a static deployment also means the whole thing is inspectable, which is a reasonable default for a directory of people who have chosen to be listed, and a question to think about carefully before you point it at a large community.

Editorial conclusion

Adopt devFind as a template if you are running a community, a cohort or a hackathon and want a member directory where people add themselves, because the fork and add a JSON file flow removes the need for a backend and an account system. Do not adopt it as a ready-made hiring platform, since it is a directory with search rather than a matching tool, and note that the search is over a data set the community curates, so an empty directory is a realistic starting state. Before you commit, look at the public/data directory to see how many profiles are actually there, and check that the Next.js and Tailwind versions in the manifest match what you want to maintain.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. shyamtawli/devFind on GitHub