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?
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.