Getting started

Set up the minimum structure first. Refine it once real work starts moving through.

1. Create a project

Sign up at getfrostbyte.dev and click New project. Use the product, client, or codebase name your team already uses. Short and recognisable beats clever.

Choose visibility and the current product stage, then create the project. Frostbyte opens the dashboard straight away. GitHub is optional and can be connected later.

The free tier gives you one project, one collaborator, and 100 active tasks. That's enough to see whether the workflow suits you before paying for anything.

2. Let the agent set things up, or don't

A fresh dashboard shows a short setup checklist: add your first tasks, add your areas, plan your first release, describe your product, and optionally connect a coding agent.

Work through it by hand, or hand a step to the Frostbyte agent. Each handoff is scoped to that step: the product-context step lets the agent write your product context and nothing else, the areas step lets it create areas, and the release step lets it draft a release with its tasks.

Connecting a coding agent is optional. Plenty of founders never do, and the checklist won't block you on it.

3. Add three to five areas

Areas are the systems you maintain, the things that don't change much release to release. A common starting set:

• Auth: login, signup, password reset.
• Billing: Stripe wiring, invoices, subscription state.
• API: public endpoints and integrations.
• UI: frontend components and pages.

Add areas inline from a task dropdown, or from the Areas tab. Rename, recolour, or archive them later as the codebase grows.

4. Create your first release

A release is what you're shipping next. Name it concretely: v1.0, MVP, Beta, or a date. Frostbyte suggests the next name based on your previous release (semver, calver, dates, sprint numbers).

Set it as active. Frostbyte allows a single active release per project, so the team always knows what "now" means.

5. Add tasks

Each task describes one change. Title, type (feature, bug, or improvement), area, release, priority. That's it. New tasks default to the active release, so you don't have to set it every time.

Drag cards between status columns (To Do, In Progress, Done) as work moves. Edit titles inline on the board. Subtasks live inside each task as a checklist.

6. Start collecting signals

A signal is anything that might change what you build next. Where you start depends on whether you have users yet.

Before you launch, you're your own best source. Capture ideas, competitor observations, and the things you keep meaning to fix straight into Signals. Reviewing one creates a task in your backlog, so nothing you thought of in month one is lost by month three.

Once you have users, turn on your Feedback Portal and share the link. Bug reports and feature requests land in Signals with their vote counts attached, and you review them alongside whatever you captured yourself. See Signals.

7. Review the scope

After a day of normal work, look at your release. If it feels achievable, keep going. If it's bloated, move lower-priority tasks to the next release or to a parking-lot release named "Later".

What's next

• Wire up your repo so commits and PRs link to tasks: GitHub integration.
• Install the Plugin so your agent can read and ship tasks alongside you.
• Review what comes in and turn it into work: Signals.