MasterPlan stores your project plan as plain JSON you can commit

The plan file is a JSON document, not a database

The design decision that separates MasterPlan from the usual project management web applications is where the data lives. The documentation is explicit: the project plan files are plain JSON text files, stored on your own computer, and easy to commit to a version control system. The history section explains why, and it is a short argument worth repeating because it defines the whole product. Most project management tools are cloud-based and browser-focused, so they are relatively heavy, they may require hosting a server to serve management pages, and they may require an account. The author also notes that data created in those tools often cannot be version controlled easily, because the project management data lies elsewhere from the source code.

The result is a simple, compiled, downloadable application rather than a service. There is no account to create and no server to run. The repository shows what that looks like in practice: an examples directory holding a couple of dozen files with a .plan extension, including example.plan, master.plan, a mario.plan and a ludumdareexample.plan, plus test files for linking, undo and redo, line maps, depth, and several board variations.

That file format is the real feature. A plan can be branched, diffed and reviewed like any other source file.

A Go program built on SDL3 bindings and a large dependency list

MasterPlan is written in Go, and the module file gives a clear picture of the stack. The module path is github.com/solarlune/masterplan and the go directive reads go 1.26, so a recent Go toolchain is needed. The top-level repository entries show a single-package layout of many small files, with names such as card.go, grid.go, page.go, project.go, selection.go, undo.go, keybindings.go, export.go, browser.go, menu.go and gui.go, alongside assets and other_sources directories.

The dependency list is where the shape of the application becomes visible. The windowing and rendering layer comes from github.com/Zyko0/go-sdl3, and the project documentation credits the SDL development team and the go-sdl2 maintenance team, with special thanks to raysan5 for Raylib, which the author calls pretty key to the development of MasterPlan. Around that sit libraries for PDF output, HTML export through chromedp, a JSON library pair, audio, animation tweening, desktop notifications, archive handling, and clipboard access through golang.design/x/clipboard.

One inconsistency is worth flagging for anyone planning a build. The project documentation directs cross-compilers to the go-sdl2 instructions, while the module file requires go-sdl3. The code and the documentation disagree about which SDL binding is in play.

One build script produces a release build per OS and architecture

Building is handled by a script written in Go, located at build_script/build.go, and the project documentation recommends a sanity check before building a release: run the program straight from the project root with go run ./, and if that works the build should generally succeed. The release build is then produced by running the build script with the build flag from the source directory, which generates a folder named bin and populates it with a release build for your operating system and architecture by default.

> go run ./build_script/build.go -b

Cross-compilation is supported in the same command, with a target OS and architecture pair as an extra argument, provided you have followed the necessary steps for cross-compilation from the go-sdl2 instructions:

> go run ./build_script/build.go -b -os windows/amd64

Dependencies are resolved automatically by the go module system, so the project documentation asks you to use a recent version of Go with support for go.mod files. The module file itself lists the direct requirements, starting with go-sdl3, xdg for the XDG base directory, semver, an HTTP download library, chromedp, a MIME type detector, desktop notifications through beeep, an audio library, URL handling, archive extraction, the zenity dialog library, a clipboard package and the clipboard library from golang.design.

Most requirements for building and running are therefore filled in by the module file and the build process itself, on all platforms, with one exception on Linux.

Linux needs a dialog helper and an X11 development package

The platform exception is worth reading twice, because it is the kind of detail that turns into an afternoon. On Linux, MasterPlan additionally requires one of zenity, qarma or matedialog for opening file selection windows, and a X11 development package, listed as libx11-dev, xorg-dev or libX11-devel, for the clipboard copy and paste functions.

That means a Linux build is not a single binary you can copy to a minimal container image. You need a dialog helper binary present at runtime and X11 development headers present at build time, and the clipboard behaviour depends on the X11 path rather than on a modern clipboard protocol. Anyone packaging MasterPlan for a server or a headless CI runner will hit this, since there is no browser mode and no headless mode described anywhere in the documentation.

The dependency list also contains golang.design/x/clipboard, which explains the X11 requirement, and github.com/ncruces/zenity, which is the Go binding for the zenity dialog tool. The three accepted dialog helpers are a sensible accommodation of the many Linux desktop environments, but the requirement is documented as a runtime dependency for the reader to satisfy, not something the build script resolves.

The licence allows use and forking but forbids redistribution

This is the part of the project that needs a careful read before any other decision, and the project documentation says it plainly: MasterPlan is not quite fully free software, although the source is available. The licence line reads MasterPlan is copyright, All Rights Reserved, SolarLune Games 2019-2021.

What the terms actually allow is more specific than the label suggests. You may use the program itself and the generated plan files in the development of projects, commercial or otherwise, since that is the point of the tool. You may build MasterPlan yourself from the repository, contribute to its development, and fork it freely. What you may not do is use any assets such as graphics files, sound files or code from the repository in any commercial creations, and you are asked not to distribute builds of MasterPlan to others.

That is a source-available arrangement with a commercial-use carve-out for the assets and a redistribution restriction on the binaries, not an open source licence such as MIT or Apache-2.0. The distinction matters for a company, since a team that wants to ship MasterPlan alongside its own product, or hand builds to colleagues, is outside what these terms grant. This is a reading of the stated terms, not legal advice, and anyone in that position should get their own reading of the licence text before acting on it.

Releases are sold on itch and Steam, and the repository is an issue tracker

The repository is not where you get the program. The project documentation states that this is the code repository and internal-ish issue tracker for MasterPlan, and that releases can be purchased from itch or from Steam, with both links given at the top of the file. The project description calls the software customizable, graphical, and aimed at independent users or small teams, and the goal is stated as a project management and visual planning tool that is easy to use and extremely simple.

The history section adds the origin story. The author was working on an indie game a few days before the initial commit to this repository, asked on Twitter for software suggestions, and found that while the suggestions were solid, they were not as applicable to independent development as wanted. The reasoning is that most project management software is designed for a large team or company, and the features that come with that, permissions, users and issue assignment, add bloat and friction for a person working alone.

The trade-off is stated plainly in the same paragraph. If you need to share plans across a whole company on an online platform, there are quite a few tools for that, and MasterPlan is not one of them. The homepage points to the itch.io page for the project. With no GitHub releases published for the repository, the build script and the source tree are the only route to a self-compiled binary.

The last push was on 2026-04-15, and no releases are published

The last push to this repository was on 2026-04-15, and the project publishes no GitHub releases. The top-level entries show an active codebase with a changelog.md and a todo directory, and the source is a complete Go program rather than a partial one, so the state on disk is a working starting point. But a desktop application that links against a moving SDL binding and a Go standard library that will keep moving is a different proposition from a library, and the dependency file shows how much surface area is pinned: chromedp, an audio stack, a tweening library, archive readers and a PDF writer all arrive with fixed versions that will age.

Two things follow for an adopter. First, you should expect to build it yourself and to maintain it yourself, and you should read the go.mod file before starting rather than assuming a clean build on an older toolchain, since the go directive is set to 1.26. Second, the plan files are the durable part of this project. They are plain JSON, they are yours, and they survive any decision about the application, which is a good reason to keep using the format even if you eventually move to something else.

For the same reason, this is a reasonable tool to try on a side project and a poor choice for anything a team depends on day to day.

Editorial conclusion

Adopt MasterPlan if you are a solo developer or a small team who wants a project board whose data lives in a JSON file inside your own repository, and if you are comfortable with a desktop application that needs a graphics stack to run. Do not adopt it if you need shared, browser-based planning across a company, a service level agreement, or a licence that lets you redistribute the program. Before committing, check three things: the licence text, which reserves all rights and forbids distributing builds; whether the Linux file dialog dependency on zenity, qarma or matedialog is acceptable in your environment; and the fact that the last push was on 2026-04-15, so plan for your own fixes rather than expecting new releases.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. SolarLune/masterplan on GitHub