Agencies & freelancers

Client work gets messy when several engagements share one backlog, decisions live in email, and nobody can tell what's ready for review. A good setup gives each client its own project, treats releases as reviewable deliverables, and offers one feedback path. The example below is a small studio running three clients without mixing their context.

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
Cadence	One agency owner per project; weekly client review and feedback triage
Agent role	Load the correct client context, work on a named task, prepare release notes for handoff

One project per client

Create one project for each client or long-running engagement. Halstead Architects and Riverside Dental should never share a backlog: different decision makers, different deliverables, different repositories, different feedback links.

Name projects after the client so the switcher stays scannable, and archive a project when the engagement ends instead of recycling it. Separation is what stops a task, agent update, or public link from exposing the wrong client's context.

Write context around the engagement outcome

Product context for client work covers the business outcome, the intended user, the constraints, and what makes the engagement successful. Don't paste the proposal or contract in. The plan needs the decisions that shape work, not the commercial detail.

For Halstead: "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."

That paragraph is enough for a new contributor, or an agent, to enter the engagement without reading a message history. See Product.

Use areas for the parts you'll maintain

Create areas like Website, CMS, Analytics, and Integrations. These persist through discovery, build, review, and later support. Skip areas for "Design phase" or "Client review"; those are stages, and stages belong to releases.

Areas earn their keep when an engagement moves into maintenance. A bug reported six months later still has an obvious home even though the original release is long complete.

Make releases match client deliverables

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

Before a review, open the release and confirm every required task is done or has an explicit exception. After approval, complete the release and write notes in client language. Implementation detail stays in the tasks, not the handoff summary. See Releases.

Collect feedback without another email thread

Enable a project-specific Feedback Portal, full or bugs-only. Give the client one link and ask for one issue per submission, with the page and the expected result. Signals keeps feedback attached to the right engagement and makes duplicates visible.

Review before converting. Clarify vague reports, link repeats, and decline out-of-scope work with a clear reason. Public intake organises the conversation; it doesn't replace scope control.

Keep agents inside the right client

Link each client repository to its Frostbyte project so switching engagements switches the project context too. Ask the agent to work from a named task, and confirm the project before broad changes.

Never paste one client's credentials or private material into another project's task. Frostbyte separates project data, but the agency still owns its repository and credential boundaries. The plugin guide covers project linking.

Run a weekly client review

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