# Startups & scaling teams

Keep project boundaries and release scope clear as the team grows.

## Who it's for

A growing team with more than one thing to ship and a steady flow of customer feedback. You need each product's plan to stay focused, and a reliable way to decide which requests become work.

## Recommended setup

Example: **Patchwork**, a fictional customer support app with a public API that ships on its own schedule.

| Piece | Example |
|---|---|
| Projects | Patchwork app; Patchwork API. One project per thing you release separately. |
| Areas (app) | Inbox, Automations, Reporting, Billing, Permissions |
| Releases (app) | 2.4.0 active, 2.5.0 next |
| Releases (API) | 3.1.0 active, 3.2.0 next |
| Members | Each team joins the project it ships |

Version numbers work well here: each project keeps its own line, and the number tells everyone what's coming next. If you ship on a calendar instead, name releases by month, such as `October 2026`. Pick one style per project.

![The RollCall Releases page: active release 1.1.0 with its progress and tasks, upcoming release 1.2.0 below it.](https://getfrostbyte.dev/images/docs/releases-page.webp "Every project has one active release at the top of its Releases page.")

## A week in the loop

1. Each team plans from its own project's active release. The [dashboard](https://getfrostbyte.dev/docs/dashboard)'s **What's Next** shows each person what to pick up, and **Project Health** flags blocked work, urgent bugs and a release falling behind pace.
2. Support and sales capture what customers say as [signals](https://getfrostbyte.dev/docs/signals), with **Capture** on the User Signals page or through the [Feedback Portal](https://getfrostbyte.dev/docs/feedback-portal-overview).
3. Once a week, review signals. Link repeat requests to the task that already covers them, so the evidence adds up on one task.
4. Make tasks for what you'll build and plan them into a release. Save the rest for later or dismiss it with a reason.
5. Ship, complete the release, and publish notes to the [changelog](https://getfrostbyte.dev/docs/release-notes-generator).

![The RollCall User Signals page with signals to review, one saved for later, and the Reviewed and Dismissed sections collapsed.](https://getfrostbyte.dev/images/docs/signals-page.webp "To review on the left, saved for later on the right. Reviewed and dismissed signals fold away below.")

## Let the evidence add up

When several customers ask for the same thing, link every signal to one task instead of making a task for each. The task collects the signals and their votes, so the most-requested work is obvious when you plan the next release.

- Marcus's request in RollCall became task #11, and its 21 votes went with it.
- The **1** chip on the task counts its linked signals. Link the next request for a reminder and it becomes **2**.

## Features that matter most

- [Signals](https://getfrostbyte.dev/docs/signals): one review queue for everything customers and your team report.
- [Feedback Portal](https://getfrostbyte.dev/docs/feedback-portal-overview): public bug reports, feature requests and voting. Feature requests and voting need Indie or above.
- [Public roadmap](https://getfrostbyte.dev/docs/public-roadmap): show customers what's planned. Indie and above.
- [GitHub](https://getfrostbyte.dev/docs/github-integration): link pull requests to tasks. Indie and above.
- [Plans & limits](https://getfrostbyte.dev/docs/plans-and-limits): Studio has unlimited projects and 10 members per project.

## Next steps

- [Projects](https://getfrostbyte.dev/docs/projects): create a project per product.
- [Signals](https://getfrostbyte.dev/docs/signals): set up the review queue.
- [Connect your agent](https://getfrostbyte.dev/docs/connect-your-agent): give each engineer's agent the same plan.