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:
- An LLM reads the submission against the connected repo's context
- It produces a structured issue — summary, observed vs expected, reproduction steps, impact, likely-affected areas of the codebase
- The issue lands in GitHub with appropriate labels (bug, priority, area)
- 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 areassection 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:
- What's your current flow for turning their feedback into something a developer can act on?
- Where would Flunes break down for your team?
- 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.
