Your client wants to see what you're working on, and you use Linear. That should be simple, but Linear was built for internal teams, not external stakeholders. There's no "share this project read-only with my client" button. So you need a Linear portal of some kind.
There are four real paths to building a Linear client portal tool, from zero-effort sharing to a full custom build. Each has different tradeoffs in cost, effort, and control. Here's how they actually play out.
Path 1: Linear's built-in sharing (public links)
Linear lets you share a filtered view of issues via a public URL. No login required. It's the fastest option with zero setup.
The limits show up quickly. Public links are truly public, so anyone with the URL can see your issues. There's no branding, no per-client filtering, and no way to require authentication. Your client's marketing lead and a random person who finds the link get the same view.
For a solo project with one trusted stakeholder, this works. For an agency with five clients who each need to see only their project, it doesn't.
Path 2: Guest seats
Linear's guest seat model gives external users real access to your workspace. They can view issues, create new ones, comment, and edit. Guests are scoped to specific teams but not to specific projects or labels within those teams.
The pricing is straightforward: $8/user/month on Basic, $14 on Business. An agency with 8 clients and 2 stakeholders per client is spending $128-$224/month on seats alone.
But the hidden cost of adding clients to Linear isn't just the bill. Guest seats give clients write access to your workspace. There's no read-only mode. Internal discussions, estimates, and capacity notes are visible unless you restructure your workflow around what clients can see.
It gets worse with multiple clients. If two clients share a team, they can see each other's work.
Guest seats work when you're inviting a contractor who needs to file bugs. They break when you're sharing progress with a non-technical client who just wants to know what shipped this week.
Path 3: Build a Linear portal yourself with the API
Linear has a solid GraphQL API with good documentation. If you have engineering time and specific requirements, building a custom portal is a real option. Here's what that actually involves.
What you need to build
Authentication and token management. You'll need OAuth 2.0 to connect to your Linear workspace. That means handling the OAuth flow, storing tokens securely, and refreshing them when they expire. Linear's OAuth tokens have scopes, so you need to request the right permissions upfront.
Data syncing. You can query Linear's API on demand, but that gets slow when a client loads a page with 50+ issues. Most teams end up building a sync layer: pull issues into your own database, keep them updated via webhooks. Linear fires webhooks for issue creates, updates, and deletes, but you need to handle webhook verification, deduplication, and ordering.
Access control. Each client should see only their issues. That means building a mapping layer: this client sees issues in this project, with these labels, on these teams. Then enforcing that on every query. One bug here and Client A sees Client B's work.
A frontend. Something that renders issues in a way that makes sense to non-technical people. Linear's internal UI is designed for engineers. Your client's project manager doesn't need to see sub-issue trees, SLA timers, or triage queues. You're building a simplified, filtered view.
Ongoing maintenance. Linear ships updates regularly. API schemas change. Webhook payloads evolve. Your custom portal is now a product you maintain alongside whatever you're building for clients.
When this makes sense
If you have a very specific workflow that no existing tool supports, or if you're a larger team with dedicated engineering capacity, building custom is defensible. You get total control over the experience.
For most teams, it doesn't make sense. You're spending weeks building and maintaining infrastructure that solves a problem other tools already handle. That time could go toward the work your clients are actually paying for.
Path 4: Dedicated Linear portal tools
A few tools exist specifically for this problem. They connect to your Linear workspace and create a separate, client-facing view that syncs automatically.
Helium Rooms (full disclosure: this is our product) lets you create branded, read-only portals per client. You choose which projects, teams, or labels to expose, and clients get their own login to see only their issues and submit requests. It's an official Linear integration, so data stays in sync without manual work. There's a free tier to try it.
SteelSync takes a similar approach with more focus on public roadmaps and release tracking. FeedVote handles feedback collection and public roadmaps. Productlane focuses on routing support requests into Linear rather than project visibility.
The key difference between these tools and the API path: someone else handles the OAuth flow, the webhook sync, the access control, and the ongoing maintenance. You configure what each client sees and move on.
What to look for in a portal tool
Filtering granularity. Can you scope a portal to a specific project, team, and label combination? Some tools only support project-level sharing, which breaks if your Linear structure doesn't map 1:1 to clients.
Authentication options. Can clients log in with their own account, or is everything public? For agencies sharing sensitive project data, login-protected access matters.
Sync reliability. Does the portal reflect Linear state in real time, or does it lag? Tools that batch-sync on intervals can show stale data. Webhook-based sync stays current.
Branding. Does the portal look like part of your service, or like a third-party tool? Clients notice.
Which path fits your situation
One client, low stakes: Linear's public link is fine. It's free and takes 30 seconds.
A few technical collaborators: Guest seats work if everyone needs write access and you're comfortable with the visibility tradeoffs.
Highly custom requirements, engineering capacity available: Build with the API. Budget 2-4 weeks for v1 and ongoing maintenance time after that.
Multiple clients, each needing a filtered read-only view: A dedicated portal tool is the practical choice. The setup time is minutes instead of weeks, and the ongoing maintenance is someone else's problem.
The worst option is defaulting to manual ways to share Linear progress with clients (Slack messages, email recaps, shared spreadsheets) because none of the above seemed worth investigating. That works for a month. Then you're spending hours per week as a human status bot, and the updates are stale by the time you send them.
Whatever you pick, keep Linear as your single source of truth. Everything else should just be a window into it.