crab.fit turns scheduling into a poll where everyone marks their own availability

The model: availability in, one slot out

Crab Fit is described as align your schedules to find the perfect time that works for everyone, and the repository description says it more directly: enter your availability to find a time that works for everyone.

That phrasing is the whole design, and it is different from the usual scheduling poll. Most poll tools offer a list of candidate times and ask people to tick the ones they can do, which produces a result you still have to interpret, because a slot with three of five people available is not the same as one with five of five. Crab Fit inverts it: each person marks the times they are free, and the tool works out which slots work for everyone.

The name is a pun on fitting, which is what the tool does, and the crab reference in the topics and in the logo asset at frontend/src/res/logo.svg is the project's branding rather than an implementation detail.

The topics list the shape of the codebase: calendar, crabs, meeting, nextjs, planning, poll and rust. So the frontend is Next.js and the API is Rust, and the calendar and poll topics describe the domain model rather than any integration with a specific calendar service. There is no mention in the README of Google Calendar, CalDAV or Exchange, and for a scheduling tool that is worth noticing: the availability data appears to be entered into Crab Fit rather than pulled from calendars, which keeps the tool independent of any provider but puts the burden of entering it on participants.

The primary language is TypeScript, the default branch is main, the last push was on 2026-04-09, and there are no GitHub releases. The licence is the GNU GPLv3, which the README states in a sentence of its own.

One structural detail from the repository layout tells you the project has more than one deliverable: there is an api/ directory, a frontend/ directory and a browser-extension/ directory at the top level.

Three parts, and two separate CI checks

The top-level entries are the clearest description of the architecture: .github/, .gitignore, CONTRIBUTING.md, LICENSE, README.md, api/, browser-extension/ and frontend/.

The frontend/ directory is the Next.js application, and the logo path confirms that the frontend is a conventional web application with a src/ directory and its own res/ folder for assets. The api/ directory holds the Rust backend, and the topics confirm rust as the backend language. The browser-extension/ directory is the third piece, and it is the one that makes the availability model work in practice.

The badge row at the top of the README names the two continuous integration workflows: Frontend Checks, at .github/workflows/check_frontend.yml, and API Checks, at .github/workflows/check_api.yml. Two separate workflows rather than one is what you would expect from a repository with a TypeScript frontend and a Rust API, since the two toolchains have different linters, test runners and build steps, and a single job would have to set up both.

The browser extension is worth thinking about, because it explains how a person actually enters their availability without leaving the calendar they look at all day. The README does not describe what the extension does or which browsers it targets, so the mechanism has to be inferred from its presence: a lightweight way to mark availability while looking at a calendar, rather than opening another tab to fill in a form.

The repository also carries a .gitignore, a CODE_OF_CONDUCT-style contribution path through CONTRIBUTING.md, and a LICENSE file at the root, alongside the source directories. The README points contributors at the contributing guide for info on running locally and submitting pull requests.

The README itself is short. Beyond the badges, the tagline, the licence line, and the sections on bugs, translations, self-hosting and contributing, it does not describe the features in detail. That is a deliberate split: the wiki carries the operational documentation and the README is the front door.

Self-hosting, and why the README bothers to mention it

The self-hosting section says Crab Fit is fully open-source and you can get your own version running by following the self-hosting guide, which lives in the wiki at the Self-hosting page.

For a scheduling tool that collects the availability of a group of people, that line is more than a feature list entry. The data a scheduling poll holds is a map of who is busy when, and that is sensitive in a way that a public repository is not. A company that would not put its staff's working patterns in a third party's database can run its own instance, and the GPL-3.0 licence is what makes that legally possible, since it obliges anyone who distributes a modified version to publish the source.

The same reasoning explains the emphasis on the wiki rather than on inline documentation. The self-hosting guide is where the actual stack is described, and the README's job is only to tell you it exists.

The browser extension fits into the self-hosted story too. An extension that points at a specific instance is a different artefact from a browser extension that points at a public service, and distributing one requires the extension to know where the server is. The README does not say how that is configured, so it is one of the questions a self-hoster will have to answer from the wiki.

The project also asks for help in two directions. The bugs and feature requests section points at a GitHub issue template with a choose link, which is the newer issue-forms mechanism rather than a plain issue list, so the repository has structured intake for both categories.

And the translations section points at Transifex, with a project page on explore.transifex.com and a note that you can join the project there, plus a link to a translating wiki page for the mechanics. Transifex as a platform means translations are managed as a hosted service with a web interface, which suits a project with contributors who do not want to edit JSON locale files by hand.

What the wiki has to carry, and what the README leaves out

The gap between the README and a complete picture is worth spelling out, because this is a project whose documentation is deliberately split.

What the README gives you is the concept in a sentence, the licence, the links, and the routes into the wiki. The badges tell you the project has two checked surfaces, a frontend and an API. The directory names tell you there is a third artefact, the browser extension, that no badge refers to.

What it does not give you is any of the mechanics. There is no description of how availability is entered, whether slots are half-hourly or free-form, whether a poll is reused, how people are invited or how a result is shared. There is no statement about timezones, which for a tool whose whole purpose is finding a time that works for everyone across locations is the first question worth asking. There is no account model, no authentication description and no statement about whether a poll is public or private. There is also no screenshot of the interface in the README body, only the logo.

The Transifex integration is the one place the README says something specific about the user experience, and it is a hint about the shape of the product: if there are many translations to maintain, the interface is text-heavy and the participants are people who read many languages. A scheduling tool that people join from a link, without an account, is a different proposition from one they log into.

The self-hosting line is the other hint. The GPLv3 licence and the wiki link are there because a shareable instance is a design goal, not a fallback. For a tool that maps out the working patterns of a group, running it yourself is the natural answer to a privacy objection, and the project leads with that rather than burying it.

So the README is doing a specific job: it tells you what the tool does, that you can run it yourself, and where the rest of the documentation is. A reader who wants to evaluate it for a team will spend most of their time in the wiki, which is where the self-hosting guide, the translating page and the contributing guide all live, along with whatever operational documentation the project maintains there.

Where crab.fit is the wrong tool

Three limits, and the first is about what the README does not tell you.

The first is the documentation gap. The README is a front door: it names the concept, points at the wiki for self-hosting and translating, and links the contributing guide. It does not describe the availability model in detail, the matching rules, the timezone handling, whether a poll can be repeated, how participants are identified or invited, or what the browser extension actually does. There is no feature list, no screenshot of the interface in the README body beyond the logo, and no API documentation. That is workable for someone deciding whether to try it, because the concept is a sentence long, but it is not enough to evaluate for a serious deployment, and the whole assessment has to be done against the wiki and the source.

The second is the self-hosting burden. A Rust API and a Next.js frontend is two runtimes to build, configure and keep patched, plus a database for the poll data, and the README gives no Docker Compose file, no configuration file list and no environment variable documentation in the body. The wiki guide will have some of that, but the point stands: the claim of being fully open-source and self-hostable is a promise, and the operational cost sits in a page you have to go and read.

The third is the absence of calendar integration. The topics name calendar, and the browser extension implies some connection to a calendar, but the README does not mention reading availability from Google Calendar, Outlook or CalDAV. If your participants' availability already lives in their calendars, entering it again by hand is the friction the tool is asking people to accept, and the browser extension is presumably the mitigation. Without the extension details, it is not possible to say how much friction remains.

The alternative approach for most teams is a scheduling poll that reads from calendars. Tools in that category, the kind that show a grid of busy times pulled from everyone, are more convenient to use and more intrusive to run, because the participant has to grant read access to their calendar. Crab Fit's model is the opposite trade: less convenient per participant, no calendar permissions required, and self-hostable if the availability data should not leave your infrastructure. That trade is worth making deliberately rather than by default.

The other alternative is to stop scheduling by poll altogether and use a rotating or rule-based approach, where the meeting time is decided by a formula rather than by consensus. For a recurring internal meeting with a fixed attendee set, that removes the coordination cost entirely, and it only fails where the meeting genuinely needs a time that suits everyone, which is exactly the case Crab Fit is built for.

Editorial conclusion

Adopt crab.fit if you are running a team or community that keeps failing to agree on a meeting time by email, because the model it uses, everyone marks availability and the tool computes the overlap, changes the shape of that conversation. Do not adopt it expecting a drop-in replacement for a full calendar product, because the README describes a scheduling poll rather than calendar sync, and the tool's self-hosting route assumes you can run the API and the frontend yourself. Verify first that you can follow the self-hosting guide with the stack you have, that the browser extension is the way your participants will enter availability or whether they will use the web interface directly, that translations are available for your participants' languages or whether the English interface is enough, and that the deployment you choose keeps participant availability data where your privacy policy says it should be.

Frequently asked questions

Official sources

1. GRA0007/crab.fit on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README