Gameplan is a Frappe forum built for teams that miss each other

The problem stated in the README: missing conversations in chat

Gameplan is described as an async-first discussions tool for remote teams, and the motivation section explains where it came from. The team had been remote first since day one, and as it grew, chat tools like Telegram fell short. Missing out on crucial conversations became a major issue, and Gameplan was built to solve the problems of modern remote work.

That framing is worth reading closely, because it defines what the product is competing against. It is not a task tracker and not a document editor. It is a forum, and its competition is the chat channel where decisions get made and then scroll away.

The four key features follow from that. Thread-first discussions let a person start a discussion and have others comment at their own pace, so nobody has to be online to contribute. Spaces categorize conversations by project, team, client or topic. Customizable profiles carry cover images, a short bio and a profile picture, which the README presents as a way to get a better picture of who is on the team. Pages act as notes for meeting minutes, proposals and ideas, and they can be private by default or shared with the team or specific spaces.

The pages feature is the one that pulls Gameplan away from a pure forum. A discussion is a conversation; a page is a document that lives in the same place. For a team whose problem is that decisions vanish into chat, keeping the decision and its discussion adjacent is a real design choice.

The project is AGPL-3.0 licensed, which for a self-hosted team tool is workable, and it is developed by Frappe Technologies, the same group behind the framework it runs on.

Three components: Frappe, frappe-ui and Redisearch

The section called Under the Hood names three projects, and each plays a specific role.

Frappe Framework is the full-stack batteries-included web framework the application is built on. That word batteries-included is the operational fact that matters: it brings its own database layer, background job system, REST API generation, authentication and site management, and it is why the install instructions talk about a bench and a site rather than a database URL.

Frappe UI is the Vue component library the interface is built from, described as a Vue UI library for a modern user interface built on a Figma design system. The README points at the design system file, which tells you the visual language is specified in Figma rather than derived from the code. Gameplan's own `frontend/` directory and the `frappe-ui` submodule in the repository layout show the split between the app's own frontend and the shared library.

Redisearch is the third piece, a search and indexing engine built on top of Redis. This is the part with a practical consequence for anyone evaluating the project: search is not a SQL `LIKE` over posts, it is a separate index. The repository's `pyproject.toml` does not list a Redis client among the Python dependencies, so the search integration likely happens at the Frappe or infrastructure layer rather than in application code, and the documentation given here does not spell out where that boundary sits.

For a platform built on Frappe, using Frappe UI and Frappe Cloud is a coherent choice, and it is also a coupling choice: you are adopting a stack, not just an application.

Docker: three commands and a wait

The Docker path is the shortest way to see the product, and it is the first thing a new user should do.

You need Docker, docker-compose and git on the machine, and then the README gives three commands:

git clone https://github.com/frappe/gameplan
cd gameplan/docker
docker-compose up

After that you wait for the setup script to create a site, then open `http://localhost:8000` in the browser, where the login screen should appear. The credentials for that first login are given in the README: the username `[email protected]` and the password `123`.

Two things to plan for. The wait is not instant, because the script provisions the site rather than serving a prebuilt image, so the first run is doing a database migration and asset build while you watch logs. And the documented credentials are public, published in the README, so a local instance is fine to poke at but the credentials need changing before that instance is reachable by anyone else.

The `docker/` directory is part of the repository rather than a separate compose file, and the same directory is where the `docker-compose` invocation is expected to run from, so the working directory matters when you run the command.

Local development: a bench, a site, and a Vite server

The non-Docker path assumes the Frappe v16 dependencies, listed as Python 3.14, Node.js 24 and Yarn 1.22, plus the Bench CLI. A local copy of frappe-ui is included in `./frappe-ui/` for development, which is a submodule, and the README says to initialise it explicitly.

Step one builds the backend. The sequence creates a Frappe v16 bench, creates a site named `gameplan.test`, pulls Gameplan's `develop` branch as an app, installs the app into the site, adds the site to the hosts file, and builds the assets:

bench init --frappe-branch version-16 frappe-bench
cd frappe-bench
bench new-site gameplan.test
bench get-app --branch develop https://github.com/frappe/gameplan
bench --site gameplan.test install-app gameplan
bench --site gameplan.test add-to-hosts
bench build --apps gameplan

Then `bench start` runs the development processes, and a second terminal can open an authenticated browser session for the site when you need one, using `bench --site gameplan.test browse --user Administrator`.

Step two is the frontend, run from the app directory. You open a new terminal and change into `frappe-bench/apps/gameplan`, then initialise the pinned frappe-ui submodule with `git submodule update --init --recursive`, install the frontend dependencies with `yarn install --frozen-lockfile`, and start the Vite development server with `yarn dev`.

The root `package.json` is a thin wrapper that delegates into `frontend/`, with scripts for `dev`, `dev:frappe-ui`, `build` and `upgrade-frappeui`, the last of which pulls `frappe-ui@beta`.

The `--frozen-lockfile` flag matters in practice: the repository ships a `yarn.lock` at the root, and a frozen install makes the build fail rather than silently updating it, which is what you want when a frontend dependency change could otherwise alter your output without anyone noticing.

One branch, two Frappe pairings, and a migration path off main

The branch policy is unusual enough to read twice. Gameplan supports Frappe v16 and newer only, and the table pairs the Gameplan `develop` branch with either the Frappe `version-16` branch for stable installations or the Frappe `develop` branch for testing upcoming releases. Gameplan does not have a separate `version-16` branch of its own; `develop` is the supported branch for both pairings, and Frappe v15 and older are not supported.

So there is exactly one branch to track on the Gameplan side, and the choice you make is about which Frappe you build against. The consequence for upgrades is that you cannot pin Gameplan to a stable line, because there is no stable line, only `develop` moving under a Frappe branch you choose.

The migration instructions for an existing installation on `main` show what a version change costs. You back up the site, switch only Gameplan to its supported branch, switch Frappe to `version-16` if the bench is on an older release, then run setup requirements, migrate, rebuild and restart:

cd frappe-bench
bench --site gameplan.test backup
bench switch-to-branch develop gameplan
bench setup requirements
bench --site gameplan.test migrate
bench build --apps gameplan
bench restart

Two warnings in the README deserve emphasis. You are told to review custom apps before switching a shared bench, because every installed app must support Frappe v16. And you are reminded that there is no Gameplan `version-16` branch to switch to, which is a strange sentence to read in a migration guide and is the clearest statement of how tightly the two codebases are coupled.

A young release line with a busy commit rhythm

The release history tells you what stage this project is at. The three most recent versions are v0.1.13 on 2026-10-20, v0.1.12 on 2026-10-19 and v0.1.11 on 2026-10-19, and the default branch is `develop` rather than `main` or `master`.

Three patch releases in two days is a fast rhythm, and for a project whose README asks you to move from `main` to `develop`, it means the supported branch is where the work is happening. That is normal for an early-stage product, and it also means there is no long-lived stable series to fall back on if a change lands badly.

The repository layout shows a project with serious process around it, which is worth noting because it cuts against the 0.1.x version number. There is an `AGENTS.md` and a `CLAUDE.md` for coding assistants, a `CODEBASE_ANALYSIS.md`, a `CONTEXT.md`, a `HANDOFF-mutation.md`, a `LIST_FAMILY_SPEC.md`, a `SHELL_EXTRACTION_PLAN.md`, a `TESTING.md` and a `TEST_SUITE_PLAN.md`, plus a `prd/` directory of product documents and a `docs/` directory. There is a `.pre-commit-config.yaml` and a `.devcontainer/`.

That mix of planning documents, product requirement documents and test plans is the profile of a young product being built in the open rather than a mature utility. It also hints at the actual shape of the work, which is not a forum backend so much as a product being specified: list families, mutation handovers, shell extraction.

The Python side is a single package named gameplan, described as a team discussion and collaboration tool, requiring Python 3.10 or newer, with dependencies on `bleach`, `bleach-allowlist` and `tinycss2`, which points to HTML sanitisation of user content. The Ruff configuration sets a line length of 110, targets py310, and formats with double quotes and tab indentation.

Editorial conclusion

Adopt Gameplan if your remote team has outgrown chat and you want a self-hosted place where decisions and notes outlive a message thread, and if you are already comfortable with the Frappe stack, because installation means a bench, a site and a Vite dev server. Do not adopt it if you need a stable tagged release, an offline-capable tool, or something that does not need a Redis search index and a Frappe site behind it. Before you deploy, read the branch pairing table and keep Gameplan on `develop`, confirm every app in your bench supports Frappe v16 before switching a shared bench, and replace the documented development login before exposing the site to anyone.

Frequently asked questions

Official sources

1. frappe/gameplan on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases