Plane for IT Studios and Agencies: Managing Client Projects

The most convenient way for an IT studio or agency to work in Plane is to run each client as a separate project inside one workspace. Work stages become statuses, each sub-issue has a single owner, the client logs in as a guest and sees only their project, requests come in through Intake, and hours are logged directly on issues. This setup takes a day to build and holds up for years if you agree on the rules from day one.

This article is for studio heads, account managers and team leads who handle five to twenty clients at once and are tired of piecing together status from chats. Below: workspace structure, client access, stage-based statuses, views for different people, documents, request intake, time tracking and a launch checklist.

Where client project management breaks down

A typical studio works like this: tasks arrive in a WhatsApp chat with the client, the spec lives in a separate document, hours are tracked in a spreadsheet, and only the project manager knows the current status. With three clients, it works. By the tenth client, things start getting lost.

The symptoms are instantly recognizable:

• Nobody can answer “what are we doing for this client this week” without a call.
• “Warranty” fixes and new work get mixed together, and the studio does for free what it should be selling.
• Monthly hours are reconstructed from memory right before the completion certificate is signed.
• The client doesn’t understand what is expected of them, and acceptance drags on for weeks.
• A developer works on three projects and learns about priorities from five different chats.

A tracker alone won’t fix this. What fixes it is the combination: a clear structure, the same statuses across all projects, and a rule that work only exists in the tracker. Plane fits this combination because issues, documents, requests and hours all live together in it.

Structure: workspace, projects, modules and cycles

A Plane workspace corresponds to the studio as a whole. Each client gets a project. If a large client has several products with different teams, create a project per product rather than per client. Inside a project, modules cover features or contract stages, cycles cover iterations, and releases capture deliveries.

It’s also worth creating an internal studio project for presales, estimates, internal development and hiring. That keeps internal discussions out of client projects that guests can access.

Plane level	What it is in a studio	Example	Owner
Workspace	The whole studio	All clients and internal projects	Studio head
Project	A client or a client’s product	“Client A — mobile app”	Project manager
Module	A feature or contract stage	“User account area”, “Payment integration”	Team lead
Cycle	A one- to two-week iteration	“Cycle 14”	Project manager
Release	A delivery to the client	“Version 1.3 in the app stores”	Team lead
Issue	An outcome the client sees	“Payment screen”	Assignee or team lead
Sub-issue	A step with a single owner	“Payment screen layout”	Assignee
Pages	Specs, meeting notes, decisions	“Meeting notes 10/12”	Project manager
Internal project	Presales, estimates, R&D	“Estimate for a new client”	Studio head

Make project identifiers meaningful: the issue prefix in a comment or commit should immediately tell you which client it’s about.

A separate workspace per client is justified in two cases: the client requires full data isolation, or they need their own server. Otherwise, separate workspaces just get in the way: the team keeps switching between them, and overall workload isn’t visible.

Client access: Members and Guests

The studio team works with the Member role, workspace administrators with the Admin role. The client is invited as a Guest and added only to their own project. The guest role is limited: the client can see issues and comment, but can’t manage settings or see other projects. The exact set of guest permissions depends on the project settings and the Plane edition, so before the first invite, create a test guest and look at the project through their eyes.

If you need finer control, for example different permissions for a client and their contractor, Plane’s higher plans include Granular Access Control. For most studios, the basic roles plus discipline about what gets written in the client project are enough.

What	Client (Guest)	Team (Member)
Issues in their project	To the extent the project settings allow	All
Other client projects	Can’t see	Sees projects they’ve been added to
Issue comments	Reads and writes	Reads and writes
Specs and meeting notes	Approved versions	All pages and drafts
Estimates, rates, margin	Can’t see; kept in the internal project	Visible to the studio head and manager
Hours on issues	Receives an export with the certificate	Logs and sees them in reports
Requests	Submits via Intake	Triages and accepts
Cycle status	Sees the project board	Sees board, table and dashboards

The main rule: write in the client project as if the client reads every word. Discussions of estimates, internal mistakes and priority disputes go to the internal project or the team chat.

Stage-based statuses and sub-issues with one owner

In Plane, statuses are configured per project and grouped into standard categories: backlog, unstarted, started, completed, cancelled. For a studio, it works well when statuses mirror the work stages and are identical across all client projects:

1. Backlog — the request is accepted but not scheduled.
2. Requirements — clarifying with the client, writing the spec.
3. Design — mockups and approval.
4. Development — code.
5. Testing — internal QA.
6. Acceptance — the ball is in the client’s court.
7. Done and Cancelled.

Each status needs an entry criterion. An issue moves to “Development” only with an approved mockup, and to “Acceptance” only after internal testing. The “Acceptance” status matters most: filtering by it shows how much work is waiting on the client, and that is a strong argument in the weekly meeting.

Break a large issue into sub-issues so that each has exactly one owner: screen design, backend, frontend, testing. An issue with no owner, or with three owners, in practice belongs to nobody.

Record dependencies with blocking and blocked by links. If the frontend is waiting on an API, the link is visible to both assignees and the manager, and a backend delay stops being a surprise on demo day.

Use labels for work type: “design”, “frontend”, “backend”, “QA”, “DevOps”, “analytics”. Two labels are a must: “warranty” for fixes covered by the contract, and “out of scope” for requests that need to be estimated and sold separately. In our experience, that second label is what pays back a tracker rollout in a studio the fastest.

Views for different stakeholders

Different people need the same issues presented differently. Plane supports saved views with filters and several layouts: list, board, calendar, spreadsheet and Gantt. For a studio, this set works:

• For the client — a board of their project by status. Nothing extra.
• For the project manager — a spreadsheet across all their projects, filtered by “Acceptance” and overdue dates.
• For the team lead — a board by assignee to spot overload and issues blocked by others.
• For the studio head — a Gantt chart by module for large projects and a dashboard of team workload.
• For the developer — “my issues” across all projects, sorted by priority.

Complex filters are easy to build with PQL, Plane’s query language, which is similar to JQL. Workspace-level views let you look at all projects at once, and they are the main tool for a manager handling several clients.

The weekly status update for the client is also built from views: what was closed this week, what’s in progress, what’s awaiting their acceptance, and which questions are open. The manager spends minutes on this report instead of half a day, and the client stops asking for status in WhatsApp because they get it regularly.

Documents and requests: Pages and Intake

Keep specs, meeting notes, architecture decisions and environment descriptions in Pages inside the client project. A document can be linked to an issue, and issues can be created right from meeting notes: a decision made in the meeting immediately becomes work with an owner. We go into more detail on what to store where in our article on team documentation without Confluence.

Client meeting notes template:

• date and attendees;
• what was shown;
• what decisions were made;
• what issues were created, with links;
• what we’re waiting for from the client, and by when.

Don’t store passwords or access keys in Pages. Use a secrets manager for those.

Intake solves the problem of requests coming from nowhere. The client or manager files a request in Intake, including via the intake email address. The manager on duty triages the flow once a day: accepts it into the project, declines it with an explanation, or marks it as a duplicate. Only triaged requests go into the backlog, labeled “warranty” or “out of scope”.

Time tracking and hourly contracts

Time tracking in Plane is tied to issues. The assignee logs hours on a sub-issue with a short comment, and at the end of the month the manager exports hours by project and reconciles them with the completion certificate. Fixed-price contracts need hours too: without them the studio doesn’t know a project’s real margin and repeats the same mistakes in the next estimate.

Rules that work:

• Log time daily, not from memory on Friday.
• Log time to a sub-issue, not to the project as a whole.
• Mark warranty hours separately; they aren’t billed to the client.
• Don’t start “out of scope” work until the estimate is approved.

Plane doesn’t replace a financial system: rates, invoices and margin are calculated separately from the export.

Kazakhstan context. Hourly contracts with Kazakhstan LLPs are usually closed with a monthly certificate of completed work, and the export of hours by issue becomes an attachment to it. Clients are used to writing in WhatsApp, so the rule “a task exists only in Intake” has to be spelled out at the start of the contract, and the manager needs time set aside to move messages over. If the client needs data stored in Kazakhstan, install self-hosted Plane on a server at a Kazakhstan hosting provider. Hosting is paid in tenge under a contract, whereas cloud plans are paid by card in US dollars. We cover which edition to choose in our article on Plane editions.

Plane launch checklist for a studio

1. One workspace for the studio, one project per client or client product.
2. An internal project for presales, estimates and discussions.
3. The same statuses across all client projects, with entry criteria.
4. Labels for work type, plus “warranty” and “out of scope”.
5. Rule: each sub-issue has exactly one owner.
6. Blocking and blocked by links for dependencies between assignees.
7. Saved views for the client, manager, team lead and studio head.
8. Page templates: spec, meeting notes, environment description.
9. Intake enabled, with someone responsible for daily triage.
10. Time tracking enabled, and the daily logging rule announced.
11. A test guest has confirmed what the client sees.
12. The first client moved to Plane, the rest after two to three weeks.

How we do it

We start a studio rollout with a diagnostic: how many clients are run in parallel, how contracts are structured, where tasks and hours live today, and which clients need access and in-country data storage. Then we launch a pilot on one client project with the real team and the real client in the guest role. After two to three weeks we adjust statuses, labels and views based on the results and move the remaining clients over.

If you’d like to go through this with support, see the Jira and Plane task tracker implementation service page: it describes the stages, timelines and what’s included in the outcome.

---

Sources. Plane plans and features: plane.so/pricing. Community Edition source code and documentation: github.com/makeplane/plane. Prices are as of October 2026 with annual billing and may change.

Terms in plain words

Workspace

The top level in Plane, shared by the whole studio. It holds client projects and internal projects, and the studio head can see the team’s overall workload.

Guest (guest role)

Access for an outside person, such as a client. A guest sees only their own project within the configured settings and can comment, but cannot see other clients or internal discussions.

Intake

A single entry point for requests in Plane, including by email. A manager triages the flow daily: accepts it into work, declines it, or marks it as a duplicate.

Module and cycle

A module groups the issues for one feature or contract stage; a cycle groups the issues for the next one to two weeks. Together they show what the studio is doing for the client and when.

Backlog

A list of accepted but not yet scheduled issues. In a studio, only triaged requests labeled ‘warranty’ or ‘out of scope’ end up there.

Blocking and blocked by

A link between issues: one can’t move until the other is done. For example, the frontend waits for the backend, and the manager sees the delay in advance rather than on demo day.

QA

Quality assurance: internal testing before the result is shown to the client. In a studio, an issue goes to client acceptance only after this test.

Granular Access Control

Fine-grained permission settings in Plane’s higher plans. Needed when, for example, a client and their contractor should see different things.