SMF·PRODUCTLANE
Can a prompt replace Productlane?
User research & feedback — customer support tied to an issue tracker
Exhibit tracking slip
Verdict
Productlane's whole design decision is that the issue tracker is the source of truth and support is a view onto it. That is a real and unusually clean idea, and it is also what makes the personal build tractable: you are not writing a help desk, you are writing a sync. The sync is where the difficulty lives — two systems, two sets of state, and conflicts that resolve wrongly in silence.
Exhibit A — The prompt
Received on31.07.2026Build an email support inbox that treats your issue tracker as the source of truth.
Ingest: a catch-all address delivered by webhook from your email provider. Thread by References and In-Reply-To headers, falling back to a token in the reply address — never thread on subject line alone, because two customers writing "Bug" become one conversation and someone reads the wrong reply.
Each thread can be linked to exactly one issue in your tracker, created from the thread or attached to an existing one. Sync in one direction only: the tracker owns status, this inbox reflects it. One-way sync is a deliberate constraint that removes the entire class of conflict bugs, and the cost — you change status in the tracker, not here — is small.
Poll the tracker's API on a schedule and reconcile, rather than depending only on webhooks. Webhooks get missed, and a support tool showing a stale status is how a customer gets told something shipped when it did not.
When an issue closes, draft a reply to every thread attached to it and hold it for a human to send. Never send automatically: the fix landing and the customer's specific problem being solved are not the same claim.
Replies go out over your provider with proper threading headers so they land in the existing conversation rather than starting a new one, and from a domain with SPF, DKIM and DMARC set up.
Out of scope: live chat, a customer portal, assignment and SLAs, and any write path into the tracker beyond creating and linking issues.Opening prefills the prompt — press enter to run it.
Exhibit B — What you lose
- B.1 the live-chat widget and in-app messaging
- B.2 the maintained Linear integration, kept working across their API changes
- B.3 shared team inbox features: assignment, snoozing, internal notes at scale
- B.4 the customer portal where users see their own tickets
- B.5 SLA tracking and reporting
Exhibit C — Why people still pay: issue-tracker-native support workflow
Because keeping a support tool and an issue tracker in agreement is a maintenance job that never finishes. The API changes, an edge case appears, and somebody has to care. That somebody is what the seat price buys.
Questions
Can I import my Productlane conversations?
Export gets you the message text; what does not travel is the link between each conversation and its Linear issue, which is the part the whole tool is organised around. Most people link the still-open threads by hand and archive the rest.
Does it work with something other than Linear?
Yes — the sync is one direction and touches four endpoints, so GitHub Issues or Jira works about as well. Productlane itself is Linear-shaped, which is exactly why a generic build is feasible here.
What does it cost to run?
A VPS with Postgres at around $10 a month plus transactional email, which is a few dollars at small volume. The tracker API calls are free within normal rate limits.
What is the one thing that does not survive the rebuild?
Someone maintaining the integration. Trackers change their APIs, and a one-person sync breaks quietly on a Tuesday; the paid product's real job is noticing before you do.
Related tools
Receipt