Agencies & freelancers

Separate client plans and turn agreed feedback into reviewable deliverables.

View as Markdown View this page as plain text

Who it's for

You build for clients, often several at once. Each client needs their own plan, a clear list of what's in the next delivery, and one place to send feedback that doesn't end up in your inbox.

Example: Halstead Architects, a fictional client having its website rebuilt.

Piece Example
Project Halstead Architects. One project per client or engagement.
Product context A website that explains the firm's services and turns visitors into enquiries
Areas Pages, CMS, Enquiry forms, Analytics
Releases Design sign-off → Launch → 1.1
First tasks Build the services pages, connect the CMS, test the enquiry form

Give every client their own project, so each one has its own plan, portal and members, and nothing from one client shows up in another's. When an engagement ends, archive it from the bottom of its Project settings. It becomes read-only, moves to Archived projects on your projects page and stops counting toward your project limit. Restore it if the client comes back.

One project per client. Finished work moves to Archived projects.

Name releases after what the client signs off before launch ("Design sign-off", "Launch"), then switch to version numbers ("1.1", "1.2") for changes after it's live. Whatever you choose, the release name is what you'd put in an email to the client.

  1. Design sign-off Completed
    Shipped October 25, 2026
  2. Launch Active
    Target December 3, 2026
  3. 1.1 Upcoming
    Target January 14, 2027

Run several clients at once

Each client is its own project, so switching clients is switching projects. The project switcher at the top of the sidebar lists them all.

Each client's card shows its stage and how much is open, so you can see where every engagement stands.
  • One portal per client. Each project has its own Feedback Portal address, so one client never sees another's requests.
  • One repository per project. Link each client's repository with auto-tracking, so your agent opens the right plan in each one.
  • Separate members. Invite a client's in-house developer to their project only. Members see the whole project, including its signals.

A week in the loop

  1. Open each client's project from the project switcher and check its active release. What's Next on the dashboard shows what to pick up.
  2. Build, or hand tasks to your agent. Before broad changes, check your agent is working in the right client's project.
  3. The client sends feedback through that project's Feedback Portal. It arrives in User Signals; nothing reaches the plan until you review it. The portal is public, so add private notes from client calls with Capture instead.
  4. Make tasks for agreed changes. Dismiss out-of-scope requests with a reason, so you can point back to the decision.
  5. When a delivery is approved, complete the release and send the client its notes.
Write the notes on the release, then send them to the client or publish them to the changelog.
Each project has its own portal, so client feedback never mixes.

Features that matter most

  • Projects: one per client. Archive it when the engagement ends; it stays readable.
  • Feedback Portal: a feedback page for each client. Feature requests and voting need Indie or above.
  • Custom domain and Widget: put the portal on the client's own subdomain or site. Studio.
  • Release notes & changelog: write up what each delivery included. Publishing makes them public, so read them first.
  • Auto-tracking: link each client repository to its project, so your agent picks the right plan.

Next steps

  • Projects: set up the first client project.
  • Team & invites: members can see the whole project, so think before inviting a client.
  • Plans & limits: Indie covers 5 projects; Studio has no project limit.

Was this page helpful?

Last updated