FAQ

Why only three states? I want one for "in review."

Three states is the whole product. Four states is a different product (a roadmap tool, an issue tracker, a kanban board), and those tools already exist and are better at what they do. The reason shipped / mock / missing works is that an exec scanning your share link can fit each region into the correct bucket in under a second. Add nuance and that breaks.

The notes field is for nuance ("shipped, but only for new accounts after 2025-01-01"). The state stays blunt.

Do my stakeholders need an account?

No, and that's the point. Share links (/share/{slug}) are public and read-only by design, so an exec can open one and read the board in 30 seconds without a login. The editor is what's gated: creating and editing boards requires signing in through your OIDC provider (Keycloak is the documented default), with owner / editor / viewer roles. Because share links are open, treat a shared board like an "anyone with the link" doc — don't put anything in it you couldn't show the people you send it to.

Can multiple people edit a board at the same time?

Yes. v1 is multi-user on Postgres, so several editors can work across the workspace. There's no real-time collaboration (no live cursors, no merge): edits save independently, and in the rare case two people change the same field at once, last-write-wins. Real-time collab is intentionally out of scope — the use case is asynchronous review.

Can I reuse a board as a starting point?

Yes — click Duplicate on any board's card in the overview. It deep-copies every screen and region into a new "… (copy)" board, with its own image files and share link, and opens it so you can change only what differs. Handy when each release or quarter is mostly the same board with a couple of screens swapped.

Why Postgres?

v1 is the team-ready cut — multiple replicas, shared state — so it's Postgres-backed. (The v0 wedge used SQLite for a single-container demo.) Bring your own Postgres, or let the Helm chart run a bundled one. Uploaded screenshots live on a filesystem volume beside it; an S3-compatible adapter is planned for v2.

Will my data survive an upgrade?

Yes, as long as your Postgres data and the uploads volume survive. Schema changes ship as numbered SQL migrations under migrations/, applied by pnpm migrate — the Docker Compose and Helm deploys run it for you on upgrade. Back up Postgres and the uploads volume together; see Self-hosting → Backups.

Can I host the screenshots on S3?

Not yet. Uploads go to a local filesystem volume (STATEBOARD_DATA_DIR), separate from Postgres. An S3-compatible storage adapter is planned for v2; the data model already separates a screen's filename from where its bytes live, so the migration will be mechanical. For multi-replica deploys today, give the uploads volume ReadWriteMany.

Does it phone home?

No. There's no analytics, no telemetry, no license server, no remote font fetching at runtime. At runtime the only outbound call is to your OIDC provider, during sign-in. The docs search runs locally on an Orama index built at compile time. See Self-hosting → Airgap considerations.

Why isn't this a roadmap tool?

Roadmap tools answer "when will it ship." StateBoard answers "what state is it in right now, screen by screen." Different question, different unit, different audience. Roadmap incumbents (Productboard, Aha!, Tempo) have already claimed the planning surface; StateBoard sits next to them, not on top.

Can I integrate Jira / Linear / Slack?

Not yet. Jira issue linking on regions is slated for v1.x; two-way Jira sync and Slack notifications for v2. Integrations are staged deliberately so the core — screens, regions, states — stays solid first. See the roadmap for where each one sits.

Why MIT and not something more protective?

The pitch is explicit on this: no BUSL games, no rug-pull. The teams who need this most run in airgapped environments where they can't trust a vendor to stay in business. MIT lets them fork it, audit it, ship it inside a product they sell. That's the deal.