Agencies & freelancers

Client work becomes difficult when several engagements share one backlog, decisions live in email, and nobody can tell what is ready for review. A useful Frostbyte setup gives each client a separate project, treats releases as reviewable deliverables, and provides one feedback path. The example below shows a small studio running three clients without mixing their context or tasks.

Recommended setup at a glance

Part	Example setup
Projects	Halstead Architects, Riverside Dental, Northgate Fitness
Halstead product context	A lead-generation website for a commercial architecture practice expanding into a new region
Halstead areas	Website, CMS, Analytics, Integrations
Active release	Client review v1
Starter tasks	Approve sitemap, build service pages, connect CMS, instrument lead forms
Ownership and cadence	One agency owner per project; weekly client review and feedback triage
Agent role	Load the correct client context, work on a named task, and prepare release notes for handoff

Give every client a separate project

Create one project for each client or long-running engagement. Halstead Architects, Riverside Dental, and Northgate Fitness should never share a backlog because they have different decision makers, release outcomes, repositories, and feedback links.

Use the client or engagement name so the project switcher stays scannable. Archive the project when the engagement is complete instead of recycling it for another client. Separation prevents a task, agent update, or public link from exposing the wrong client context.

Write context around the engagement outcome

Product context for client work should explain the business outcome, intended user, important constraints, and what makes the engagement successful. Avoid copying the proposal or contract into Frostbyte. The plan needs the decisions that shape work, not every commercial detail.

For Halstead, a useful description is: “A lead-generation website for a commercial architecture practice expanding into a new region. Prospective clients need to understand services and submit qualified enquiries. The client must be able to update projects without developer support.”

This context makes task and agent decisions more precise. It also gives a new contributor enough background to enter the engagement without reading an entire message history. See Product context.

Use areas for the parts you will maintain

Create areas such as Website, CMS, Analytics, and Integrations. These describe systems that persist through discovery, build, review, and later support. Do not create areas for Design phase, Development phase, or Client review. Those are stages or deliverables.

Areas are especially useful when an engagement moves into maintenance. A bug reported six months later still has an obvious home even though the original release is complete.

Make releases match client deliverables

Name releases after something the client can review or accept: Sitemap approval, Client review v1, or Production launch. Include only the tasks required to reach that state. This creates a cleaner conversation than a release named after a month or an internal sprint.

Before a review, open the release and confirm that every required task is done or has an explicit exception. After approval, complete the release and generate notes that explain what changed in client language. Keep internal implementation detail inside tasks, not in the handoff summary. See Releases.

Collect feedback without another email thread

Enable a project-specific Feedback Hub or public bug reporter. Give the client one link and ask them to submit each issue separately with the page, expected result, and relevant context. The queue keeps feedback attached to the correct engagement and makes duplicates visible.

Review submissions before turning them into tasks. Clarify vague reports, link repeated requests, and decline work outside the engagement scope with a clear explanation. Public intake organizes the conversation; it does not replace scope control.

Keep agents inside the correct client context

Link each client repository to its Frostbyte project. When you switch engagements, repository auto-tracking should switch the project context too. Ask the agent to work from a named task and confirm the project before applying broad changes.

Do not paste one client's credentials, private requirements, or source material into another project's task. Frostbyte separates project data, but the agency still needs disciplined repository and credential boundaries. The agent plugin guide covers project linking.

Run a weekly client review

1. Check the active release and remove anything that does not support the next deliverable.
2. Confirm every open task has an agency owner and a next action.
3. Triage new client feedback, then convert only agreed work into tasks.
4. Send a short release update that names completed work, open decisions, and the next review point.

Apply this setup

1. Create one project per client and write engagement-specific product context.
2. Define three to five stable areas for the systems you will build and maintain.
3. Create an active release named after the next client-reviewable deliverable.
4. Share one feedback link and connect the correct repository to the project.