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