I built Feedvote because I kept running into a simple product problem: our team wanted to keep planning in Linear, but customers and stakeholders needed a much narrower view of what was happening. Giving every customer a Linear seat was the wrong boundary. It exposed an internal workspace, added account friction, and made it too easy to share implementation details that were never meant to be customer-facing. So I treated the customer roadmap as a controlled projection of Linear , not as a second project-management system. Disclosure: I'm the founder of Feedvote , the product described here. The separation that made the workflow click The internal system and the customer-facing system have different jobs: Linear remains the source of truth for delivery work. The public or customer portal contains only selected issues and projects. New imported work starts team-only so someone can review it before publishing. A team can publish an item publicly or assign it to specific customer contacts. Customer feedback and votes are moderated before becoming Linear work. That last point matters. A public feedback board should not be able to write arbitrary issues directly into an engineering backlog. The moderation step is a trust boundary, not just an admin feature. The basic data flow The useful workflow ended up looking like this: Select the Linear teams, projects, issues, or labels that are eligible to sync. Import those items into a private review state. Rewrite or trim customer-facing copy when internal detail should stay private. Publish the approved items to a public roadmap or a customer-specific portal. Collect feature requests, votes, and comments outside Linear. Merge duplicates and approve the feedback that deserves engineering attention. Send approved feedback into Linear. Sync delivery status back to the roadmap and notify voters when something changes. The important part is that customers never need access to the Linear workspace. They interact with the roadmap, while the product team keeps using the tool it already uses. Three implementation details that were easy to underestimate 1. Visibility is a field, not a side effect An item being present in Linear does not mean it should be public. I needed an explicit customer-facing visibility state that could be reviewed and changed independently from the Linear issue. This also makes customer-specific roadmaps possible. The same internal project can be relevant to one account, several accounts, or everyone. 2. Statuses need a translation layer Internal workflows often have statuses such as Triage, Blocked, or Ready for QA. Those labels are useful to the team but noisy or confusing to customers. Instead of mirroring every internal state literally, the customer-facing layer maps them into a smaller set such as: Under consideration Planned In progress Shipped The Linear issue can keep its full workflow while the customer sees a stable, understandable lifecycle. 3. Two-way sync needs ownership rules "Two-way sync" sounds simple until both systems can change the same field. The rule I use is to be explicit about ownership: Linear owns delivery state. Feedvote owns customer visibility, public copy, votes, and portal access. Approved customer feedback can create or link to Linear work. Linear status changes flow back to the linked roadmap item. This avoids a generic last-write-wins model, which can silently overwrite the wrong thing. Closing the loop is the real value Collecting feedback is only half the job. The moment that creates trust is when a customer gets an update without having to ask again. That means the feedback record, roadmap item, and Linear issue need to stay linked. When delivery moves forward, the customer-facing status changes. When the work ships, the people who voted can be notified. I published the integration in the Linear directory , and I'm continuing to improve the workflow based on how Linear-first teams share progress with customers. If you're building a similar integration, I would start with the permission boundary and field ownership rules before building the UI. Those two decisions shape almost everything that follows. I'm happy to answer questions about the sync model or the trade-offs behind customer-specific versus fully public roadmaps.