Hello there (General Kenobi's favorite way to start the conversation),

I’m Rashid, a sophomore at UT Austin. I built Rejourney.co (https://rejourney.co/) to predict issues with your apps and websites before they happen, based on real user session recordings.

Here is a silly video (with cats) on how it works: https://www.youtube.com/watch?v=Z95MDxBXMjk

It’s open source, and the post link is the github repo, but here it is again: https://github.com/rejourneyco/rejourney

I originally built this because I had a campus freebie finder app that grew quickly, and I had a lot of users dm me on instagram about issues with the app’s onboarding and UX confusion. I initially lost about 340 users out of my 5,000ish users because of these issues, and I had to recover some by nudging them with notifications. It was a big pain, and I felt bad that I lost this many users to small and easy fixes. So I built Rejourney to predict that before it happens. Here is how it works:

First, the SDK is installed on Web JS, Swift, or React Native apps. You then help the SDK a little with a few lines of tracking important events -- such as a subscription bought, a signup completed, etc -- before you ship the app. We called these “critical conversion events”.

From here, Rejourney records the user session along with the meta data you set up, and relates it to the sequence of the user journey, each touch/scroll/pan interaction, and rage taps. If deemed an issue, it bundles in API response times and codes, ANRS, and crash traces into the context.

A heuristic then bundles all the user recordings into similarity cohorts for processing, and finds similar user journeys and outcomes in relation to the critical conversion actions that matter to you. If a trend is found that is possibly worrying, it admits the user recordings into segmentation and processing by an LLM on our back (in this case Gemini for cost and speed, but it has been tested on GPT 5.5 if you decide to self-host and set this up on your side).

If the LLM views similarities in the touch sequence frame by frame, it can determine whether the cohort is likely to present a negative outlook on the critical conversion event that matters to you. Based on the replays and all the surrounding context, it outputs a .MD file with the context and the fix that would patch it (which you can copy into your coding agent). Optionally, you can attach your github repo so the .MD file includes a code fix with the detected issue.

Furthermore, this occurs at the scale of thousands of user recordings daily. We have seen how this works on a medium-scale, as Rejourney has been tested with about 2.5 million user recordings from people shipping the SDK. One of our users even emailed us reporting a 30% increase in onboarding after 2 weeks of fixing non-stop issues found.

We have made it soooo cost effective to run with different strategies, that our first 3 paid users made us break even on costs…and this means more compute space for cool things later :D

Other considerations and criteria: Privacy was also very very important as we have to consider GDPR, after the retention period (usually 7-days) we quantize all the user recordings, anonymize all the fingerprints and aggregate them into a general dashboard (similar to Firebase’s general analytics dashboard).

I’d love to hear your feedback, critics, and requests in the comments! I’m all ears (or eyes since I’m reading).

> Endpoint views break down request volume, errors, latency, and status codes. Crash and ANR detail adds the app version, device, and thread context around a failure. This is where a problematic UI transition can be connected to a backend or runtime condition.

The project README reads like a first draft straight out of Claude, and it's incredibly off-putting. The 'Show HN' post here is so much better; clearly you're capable of writing a decent explanation of what this project is, its history, and for whom you've built it. Take the time and write the damn README yourself.

If you expect human attention, put in human effort.

You're a sophomore at UT, so as a UTCS alum (:wave: from a fellow Turing Scholar) I'm not letting you off the hook. Unless things have majorly changed, I know you're taking 6 hours of writing-heavy coursework.

This looks really interesting. I've used LogRocket a lot across a number of businesses with varying volume, mainly to try to uncover these kinds of issues. I know they have an AI layer now but I'd love to try this as an AI native alternative which gets straight to the problem solving. It could save hours of manually watching playback and a lot of effort coming up with potential problems/solutions etc.

[flagged]