How a LinkedIn post at midnight became a SaaS

A few months ago I was scrolling LinkedIn at midnight — the exact time of day when every post feels either life-changing or stupid, and you can’t tell which. I stopped on a short demo video. Someone had embedded a feedback form on a marketing site, typed “the CTA button should be cyan, not green,” and, live on camera, a pull request appeared on their GitHub repo seconds later. Claude had read the page, found the component, and rewritten it. The video had a couple thousand likes and a lot of comments saying some version of “this is a toy” or “cool but fragile.”

I watched it four times. It didn’t matter if the demo was held together with string — the shape of the idea was obviously correct. Most feedback tools stop at the handoff: they give you a polished inbox, a public roadmap, a voting widget, and then they hand you a spreadsheet and wish you well. Everything interesting happensafter the handoff, and that’s where nothing exists.

The gap the demo was pointing at

Every product team has the same backlog shape. The top 20% of tickets are real: architecture changes, new products, things that need a human. The bottom 40% are landfills: “typo on the pricing page,” “button is slightly too small on mobile,” “can you make the confirmation email bold.” They’re obvious, they’re cheap, they’re boring, and theynever get done because every engineer with the skills to do them is busy doing the top 20%.

What the LinkedIn demo implied — even if the demo itself was a scaffold — was that agents are now good enough to absorb that 40%. You don’t need to triage “button too small on mobile” into a ticket anymore. You can let an agent read the repo, diff the component, open a PR, and put a human in the loop only at review time. The bottleneck stops being engineer-hours and becomes reviewer-hours, which is a much cheaper constraint.

Why the existing incumbents won’t do this

Canny, Featurebase, UserVoice, Productboard — they’re all good at what they do. None of them will ship this. Three reasons:

• It’s a different buyer. Their ICP is a PM. Ours is an engineer. PMs don’t want PRs opened without their planning ritual; engineers do.
• It’s a different risk profile. A code-writing integration requires a GitHub App, write scopes, branch protection awareness, and a legal review. You can’t bolt that onto a vote-counter.
• It’s a different disposition. They sell certainty. We sell “here’s a PR, review it.” That requires a team comfortable with an agent in their repo, which is a much smaller market today and a much larger one in two years.

The first commit

Two days later I registered feedbackiq.app, wrote the first commit at 11:47pm, and opened a Next.js app with exactly three pages: a landing page, a dashboard shell, and a widget script. The scope was aggressive: in the first week I wanted a working path from “user submits feedback on a demo site” to “Claude opens a PR on a connected repo.” It took nine days, most of which was GitHub App permissions and not the AI.

This blog is the series about what came after. Every post is one decision, one tradeoff, or one thing we got wrong the first time. Next up: picking the stack — why Next.js 16, Prisma on Neon, Clerk auth, Vercel AI Gateway — and what I specifically did not pick, and why.

If you’re the person who made that LinkedIn demo: thank you. The commenters were wrong.