DEV Community

Alex Quach
Alex Quach

Posted on • Originally published at flunes.com

Flunes: turning 'it's broken' into real GitHub issues, via one link

The problem that wouldn't go away

Every client project I shipped ended the same way: a flood of bug reports
arriving as Slack screenshots, half-finished emails, voice memos, and the
classic "the button is broken on my phone."

None of it was actionable. Every Friday I'd burn 2-3 hours translating
fuzzy human feedback into proper GitHub issues a developer could pick up
Monday morning.

I tried the usual suspects — Linear forms, Canny, Notion intake docs, a
Typeform piped through Zapier. They all had the same failure mode: my
non-technical clients didn't want to fill them out. Too many fields, too
much process, "where do I click again?"

So I built Flunes.

What it does

One link. That's the whole pitch to a collaborator.

They open it, write what's wrong in plain English, attach a screenshot
if they feel like it, hit submit. On the other side:

  1. An LLM reads the submission against the connected repo's context
  2. It produces a structured issue — summary, observed vs expected, reproduction steps, impact, likely-affected areas of the codebase
  3. The issue lands in GitHub with appropriate labels (bug, priority, area)
  4. The collaborator gets a confirmation. They never see GitHub. They never create an account. They never see anything you or I would call "technical."

The bet: the bottleneck isn't getting feedback. It's getting feedback
in a shape a developer can act on without 20 minutes of triage.

How the repo-awareness works (the part I want to talk about)

The naive approach is "embed every file in the repo, retrieve top-k at
submission time." I tried it. It was noisy and expensive.

What actually worked:

  • Index file paths and directory structure on repo connect
  • Generate a one-paragraph summary per top-level directory
  • Pull recent commit messages and open issues for vocabulary
  • At submission time, do a single LLM call with the submission + that compact repo manifest as context
  • Output a structured issue with a likely-affected areas section that references actual paths in the repo

This gives the collaborator's report grounding without dragging full
file contents into the prompt. A bug report saying "the login screen is
slow on Safari" comes out the other side referencing
apps/web/features/auth/ instead of guessing.

It's not magic. It's wrong sometimes. The AI disclaimer on every
generated issue is real, not theater.

Stack

  • Next.js 15 on Cloudflare Workers (OpenNext). Cheap to run, fast cold starts, scales to zero.
  • Supabase for auth + Postgres. Worth every cent of the free tier.
  • GitHub App for repo access — never asked for a personal token, scoped per-install.
  • Polar for billing, routed through Hookdeck for webhook reliability. Stripe-tax-style headaches without the Stripe price tag.
  • Tiptap for the editor on the submission page.
  • next-intl because the second user who tried it was in Germany.

What's free vs paid

  • Free: 1 repo, unlimited collaborators, unlimited submissions, AI structuring, GitHub issue creation.
  • Starter / Pro add more repos, screenshot quotas, and higher AI usage caps.

Free tier is not a trial. It's a working product. I'd rather have you
use it than churn.

Lessons from building this

  • The submission form is the product. I spent more time on the collaborator-facing page than the dashboard. If a non-dev quits after 10 seconds, nothing else matters.
  • AI output needs an obvious "this was machine-generated" tag. Devs reviewing issues want to know what to trust.
  • Webhook reliability is its own product surface. Polar webhooks dropping silently cost me a week. Hookdeck in front of them was the fix.
  • Cloudflare Workers + Next.js is genuinely good now. A year ago I would not have recommended it. Today, yes.

What I want from you

If you ship to non-technical users — clients, internal stakeholders,
beta testers, your mom — I'd love to hear:

  1. What's your current flow for turning their feedback into something a developer can act on?
  2. Where would Flunes break down for your team?
  3. What kind of bug report would you throw at the AI to see it fail?

Drop a comment, or try it and break it. Free
tier covers everything you'd need to evaluate it.

Thanks for reading.

Top comments (0)