Inspiration
We've all had conversations we wish we could redo. A difficult discussion with a manager, negotiating a salary, setting boundaries with someone, or delivering uncomfortable news. Sometimes, the right words only come to us afterward.
That frustration inspired Rehevia.
Most people prepare for important conversations by thinking about what they'll say. But real conversations rarely follow a script. The other person might disagree, interrupt, become defensive, or ask something unexpected.
I wanted to build a place where people could experience those moments before facing them in real life.
Rehevia's guiding idea is simple: Practice it before you say it.
What it does
Rehevia is a voice-first AI conversation simulator that lets people practice difficult conversations with a realistic AI counterpart.
Instead of reading advice or chatting with an assistant that always agrees, users enter a conversation room and actually speak.
The experience follows a practice loop:
1. Prepare
Choose from 12 curated conversation scenarios or create a custom situation. Define what you want to achieve and prepare for the discussion.
2. Practice
Enter a live voice conversation with an AI counterpart. The counterpart can challenge your position and introduce resistance, making the experience more realistic than a predefined script.
3. Reflect
After the conversation, receive a structured debrief to understand how the discussion unfolded and identify opportunities for improvement.
4. Rewind and try again
Revisit important moments and explore how different responses could change the conversation.
The goal is to create a repeatable learning experience where users can experiment, reflect, and gradually become more comfortable handling difficult conversations.
Rehevia also includes Pro access and a High-Stakes Pass model for its premium practice experiences.
How I built it
Rehevia is built as a mobile application using React Native, Expo, and TypeScript.
Supabase provides authentication, database services, and server-side functions. Apple Sign-In supports authentication on iOS.
The conversation experience combines OpenAI's Realtime capabilities with WebRTC to enable live voice interactions. A structured resistance engine helps control the counterpart's behavior, while the application manages conversation states, interruptions, and recovery.
The backend handles session authorization, credit consumption, entitlement reconciliation, scenario compilation, and debrief generation through dedicated Supabase Edge Functions.
RevenueCat manages subscriptions and purchases. Sentry supports error monitoring and operational diagnostics.
A significant part of the development effort went into connecting these systems reliably. A successful purchase needs to unlock the correct features, a reconnect must preserve the session, and a temporary interruption should not erase the user's progress.
The architecture separates the conversation lifecycle, access control, and purchase state so these components can be tested independently.
Challenges I ran into
One of the biggest challenges was making the complete experience reliable on a physical iPhone.
RevenueCat and subscription activation
The development app initially couldn't retrieve products from App Store Connect because its bundle identifier differed from the production app. I configured RevenueCat's Test Store for development while preserving Apple's store configuration for release builds.
I also encountered a purchase flow where the transaction succeeded but Pro activation remained stuck. The application was waiting indefinitely for backend reconciliation. The flow was repaired so valid entitlements unlock access immediately, while backend reconciliation runs with a bounded timeout.
Real-time conversation interruptions
The conversation room could connect successfully and then unexpectedly pause or disconnect. Reconnect and Resume sometimes competed with each other, leaving the user in confusing states.
The investigation identified an unsupported parameter in an initial Realtime tool request as a likely interruption cause. I removed it and reworked the room lifecycle around explicit state transitions, bounded recovery, and reliable cleanup. The original provider rejection could not be conclusively verified because its error code had been discarded.
Performance and diagnostics
WebRTC statistics were being polled approximately every 130–150 milliseconds, flooding the development console.
I reduced audio-meter polling to at most once per second and preserved useful warnings and errors.
I also removed raw diagnostic JSON from the normal room interface and moved sanitized diagnostics into a development-only view.
Session and credit integrity
Reconnecting should never create duplicate sessions or charge users again for the same eligible practice. This required careful handling of authorization, session identity, backend idempotency, and recovery paths.
The resulting system has automated coverage for these behaviors, with final physical-device verification still underway.
Accomplishments that I'm proud of
I'm proud of turning a simple idea about practicing difficult conversations into an integrated mobile prototype.
The project now brings together live AI conversations, structured practice scenarios, debrief generation, subscription management, and session recovery.
I'm particularly proud of the reliability work. It required addressing problems across mobile state management, real-time connections, purchase synchronization, and backend authorization.
The latest reported validation included 696 passing mobile tests and 31 passing contract tests for the room repair work.
These automated results are an important milestone, although the repaired experience still needs its final round of physical-iPhone testing.
What I learned
Building Rehevia taught me that the conversation experience depends on much more than the intelligence of the AI model.
Latency, microphone handling, connection recovery, and consistent session state all shape whether a live interaction feels natural.
I also learned how important it is to separate a successful transaction from the backend processes that follow it. Users should not remain stuck after a purchase that has already granted the required entitlement.
The project reinforced the value of clear lifecycle ownership, meaningful diagnostics, and testing failure scenarios rather than focusing only on the happy path.
Most importantly, I learned that building a convincing AI experience requires paying as much attention to what happens when things go wrong as to what happens when everything works.
What's next for Rehevia
My immediate priority is completing physical-iPhone verification of the conversation room, reconnection behavior, and purchase experience.
After that, I want to refine the practice and debrief experience, expand the scenario library, and gather feedback from real users.
I also plan to improve how users can revisit important moments, compare attempts, and track their development over time.
The long-term vision is to make Rehevia a practical companion for preparing for conversations that matter.
Practice. Reflect. Progress.
Built With
- apple-sign-in
- expo-application-services
- expo.io
- onesignal
- openai-realtime-api
- postgresql
- react-native
- revenuecat
- sentry
- supabase
- supabase-edge-functions
- typescript
- webrtc
Log in or sign up for Devpost to join the conversation.