I built an AI agent that opens GitHub PRs on your SaaS. Here's how it went.
I've wasted so much time staring at PostHog funnels.
Like, I know that 40% of users drop off between signup and connecting their first integration. I can see it. The funnel just sits there mocking me while I go fix some unrelated bug or ship a feature nobody asked for.
The actual problem isn't finding the friction. It's that turning "users drop off here" into a PR takes maybe 2-3 hours I never seem to have. So the data rots.
I got frustrated enough to just build the fix myself. Velyr connects to your PostHog and your GitHub repo, finds the drop-off, writes the fix, and opens a PR. Then it pings you on Telegram, just a message like "hey, 38% of users quit on this step, I wrote this fix, want me to open the PR?" You say yes or no. That's it.
Nothing touches production automatically. No auto-merges. I'm paranoid about that stuff too, so I designed it so you always have to explicitly approve before anything hits your repo.
Opening it up with a 14-day free trial right now.
Genuine question for anyone who's been in this situation: if a tool messaged you with a concrete fix for a drop-off you already knew was there, would you trust the PR, or would "AI touched my repo" be a dealbreaker regardless?
I would trust it as far as I can read the diff, which matters more than the approval gate itself. A funnel fix reads as a harmless flow change, so it gets a quick yes. But if that same diff also shifts who can reach a step, that is what slides through on a rubber-stamp. Less an AI touched my repo problem, more a what am I approving here one.
Interesting idea.
I've been building an AI companion for the last few months, and I've noticed a similar pattern. Finding the problem is usually easy. The hard part is finding the time and focus to actually fix it.
Personally, I wouldn't let AI merge anything automatically, but I'd definitely be interested in reviewing a PR that comes with a clear explanation of what it changes and why.
I like how you've combined user data with actionable insights it's a real time saver. Have you considered how you might measure the impact of your tool on user retention over time?
genuinely curious what the PRs actually look like in practice. can you share a real example of a drop-off Velyr identified and the PR it generated, even anonymized. the abstract description is compelling but the PR quality is what determines whether this becomes part of someone's workflow or gets trialed once and abandoned. a concrete example would also answer the AI in my repo concern better than any reassurance about the approval flow
The human-review boundary matters. I use AI around Kinetic Override for scaffolding/copy, but Android 15 gesture replay, AccessibilityService behavior, and timing loops still need real-device verification before I trust any change.
I would trust it if the PR came with the same evidence I expect from a careful teammate: what metric triggered it, what path it changed, what test or repro proves the fix, and what it deliberately did not touch.
The approval gate is necessary, but the bigger trust-builder is making review cheap. If the agent can say "signup -> integration connect dropped here, I changed only this empty-state branch, here is the before/after behavior," then reviewing feels like checking a focused patch instead of auditing a mystery box.
For early users, I would probably bias the product toward smaller PRs and better review notes over more ambitious fixes. A boring 80-line PR that explains itself is much easier to say yes to than a clever 600-line one.
I’ve run into the same issue with PostHog funnels: you clearly see where users drop off, but turning that insight into an actual fix rarely happens because of time and mental overhead.
The “insight → PR” step is really the missing link between analytics and execution.
My main question is: how do you make sure the PRs don’t break existing flows or edge cases?
The manual approval before merging is definitely a solid safeguard.
Mechanically, what you've built is a threshold drop: the funnel insight was always worth 2-3 hours, but anything that costs 2-3 hours loses to the backlog forever, so the data rots exactly like you said. Velyr moves the marginal cost of acting on a known drop-off from hours to one yes/no tap, and that's the entire trick. I ship a small iOS app solo, and my version of your PostHog moment is knowing precisely which onboarding screen leaks and still not touching it for three weeks. The approval gate matters more than the codegen here — nobody fears an agent that drafts, everybody fears one that merges. The Telegram ping is the product; the PR is just the payload.
Honestly, if it's trapped behind a manual review gate where a human has to explicitly approve the handshake before anything hits main, I'd absolutely use it. Funnel leakage is one of those annoying things that always gets pushed to the bottom of the backlog anyway. Neat concept, love the Telegram ping idea to keep it fast.
Thanks, yeah that was exactly the idea. Funnel stuff is the classic "we know it's broken but we'll fix it later" thing that just never becomes a priority. If an agent does it every week and you just hit yes or no, it actually gets done.
This really hits home. The "2-3 hours I never seem to have" problem is exactly what I keep running into. For me, it's not even the code fix itself, it's the PR description, commit messages, inline comments. I'd figure out the fix and then spend 30 more minutes just writing about it.
The no-auto-merge plus Telegram ping setup is smart. I landed on the same basic idea for my own tool, the AI should handle the mechanical stuff, but a human should always make the final call.
On the writing side of this problem: I built DictaFlow (dictaflow.io) for exactly this bottleneck, hold-to-talk dictation that works in any IDE. I dictate PR descriptions and commit messages now instead of typing them. Different part of the pipeline than Velyr, but same idea, reduce the friction between knowing what to do and actually doing it.
The 'no auto-merge' and Telegram ping feature completely removes the 'AI touched my repo' fear for me. If I can review the PR just like a human team member's code, it's a huge time saver.
Quick question: How does Velyr handle complex codebases with a lot of custom UI components? Does it ever hallucinate dependencies?
Glad the approval flow makes sense.
On the codebase question: it reads your actual repo before writing anything so it's not going in blind. Larger repos work fine too, and I'm actively improving the repo traversal so it gets even better at navigating complex setups. Either way the PR format naturally catches anything that needs a second look, same as with any code from any source. If you want to see how it handles your specific stack, the 14-day trial is probably the most honest answer I can give.
To your question: "AI touched my repo" alone isn't a dealbreaker for me — but the trust threshold depends entirely on what the AI touched and how verifiable the change is.
A PR that rewrites a single onboarding step based on a clear drop-off signal? I'd review and merge that in 10 minutes. It's bounded, the intent is obvious, the diff is small.
A PR that modifies auth logic or data models? I'd want to understand the full reasoning chain before touching merge. Not because I don't trust the AI, but because the blast radius of a mistake is orders of magnitude larger.
The design you described — explicit approval, no auto-merge, Telegram ping with context — is exactly right. You're not asking me to trust the AI's judgement. You're asking me to trust my own judgement about whether a specific, bounded diff looks correct. That's a very different ask.
The remaining friction is probably: how good is the fix quality? A PR that misdiagnoses the drop-off cause and ships a wrong fix would erode trust faster than never building the tool at all.
Yeah that's exactly the scope Velyr stays in, UI and UX only. Copy, layout, onboarding friction, CTAs. It doesn't touch auth, data models, or any actual app logic, that's a hard boundary.
So the diff is always something you can eyeball quickly, no reasoning through business logic required.
I’d be careful treating trust in the PR as the main decision.
A lot of founders already trust humans to ship bad fixes and AI to ship good ones.
The harder question is whether the user believes Velyr identified the right problem before it started writing code.
That distinction matters because the adoption bottleneck may sit earlier than the PR itself.
I wouldn’t make the actual call casually in-thread because it changes what users think they’re approving in the first place.
Fair point, the way it works is you see the reasoning before the code. Here's the drop-off, here's the data, here's what I'm proposing to fix. So you're approving the diagnosis as much as the diff. Whether that's enough to build confidence in the problem identification, that's something I'm still figuring out honestly.
That's exactly why I'd be careful.
Once users can review the reasoning, the question stops being "do I trust the code?" and starts becoming "do I trust what Velyr thinks is worth fixing?"
The useful part is figuring out where that confidence actually gets earned.
I wouldn't make that call casually in a thread because it can change the onboarding, approval flow, and what users believe they're adopting in the first place.
If you'd like the tighter version, drop your email and I'll put it together properly.
Appreciate the offer, but I think what I've got is solid for now. The feedback is valuable though, something to keep an eye on as I talk to more users.