What is Frostbyte?
What Frostbyte is, who it's for, and how signals, projects, releases, areas, and tasks fit together.
Frostbyte is a product-development tool for solo SaaS founders and small teams. Collect real user signals, decide what matters, and turn the strongest ones into a focused release you can ship.
Everything runs through one loop: feedback comes in, you review it, the work worth doing lands in a release, and the release ships. No heavyweight process on top.
Who it's for
Small dev teams of two to ten: indie founders, startup teams, and engineering groups inside larger orgs that want out of Jira. If your planning tool asks more questions than it answers, Frostbyte is for you.
It also works well with coding agents. Indie and higher include the Agent Plugin and full MCP access, so Claude Code or Codex can read, pick, and ship tasks alongside you.
The five concepts
Five pieces cover the whole model. There are no epics, swimlanes, or nested hierarchies to maintain.
Projects
A project is a workspace, usually one per product or codebase. Each has its own signals, releases, areas, tasks, members, activity feed, and Feedback Portal. You can belong to many projects and switch between them from the sidebar. See Projects.
Signals
A signal is an input worth acting on: a bug report, a feature request, a piece of feedback, or an observation you captured yourself. Public submissions arrive through your Feedback Portal; everything else you capture by hand or through your coding agent.
Signals are reviewed, never auto-committed. Each one gets a decision: create a task, link it to existing work, save it for later, or dismiss it. Accepted signals become tasks that keep the original input attached as evidence. See Signals.
Releases
A release is what you're shipping next. It has a name (v1.4.0, MVP, Beta, or a date), a status, and an optional target date.
Frostbyte enforces a single active release per project: setting one release active demotes the previous one to upcoming. It's the most opinionated choice in the model, and it exists to keep "what are we shipping now?" answerable in a second. New tasks default to the active release. See Releases.
Areas
An area is a part of your system you maintain over time: Auth, Billing, API, Frontend. Areas don't have a lifecycle. They exist as long as the system they describe exists. Each task tags to one area, so you can filter the board by the part of the codebase it touches. See Areas.
Tasks
A task is one unit of work: a feature, a bug, or an improvement. Each has a type, priority, and status, plus an optional area, release, and assignee. Tasks support inline editing, drag-and-drop between status columns, subtasks, and stable URLs you can share. See Tasks.
How a week flows
Review what came in. Turn the signals worth acting on into tasks. Scope those into the active release, tag each one to the right area, and start working. The Activity feed records every change, so the team can catch up after a day off without reading every Slack thread.
When in doubt, keep releases short and tasks small. If a release feels bloated, split it. If a task feels too big, break it into subtasks or two separate tasks.
What's next
- Set up your first project: Getting started.
- Review what comes in and turn it into work: Signals.
- What each tier unlocks: Plans and limits.