Fork

Don’t ask what to choose. Explore what each choice changes.

Comment

Inspiration

Some decisions are difficult not because we lack information, but because we cannot clearly see how each choice could change what happens next.

Most AI assistants approach decision-making like a question-answering problem: you describe a situation, and the AI gives you a recommendation. We wanted to build something different.

Fork doesn't decide for you. It helps you see what your decision changes.

That idea became Fork: a visual decision-exploration app that turns a difficult choice into multiple possible paths. Instead of producing an "AI-approved" answer, Fork exposes the tradeoffs, assumptions, risks, uncertainty, and consequences behind each option while leaving the final decision with the user.

For the RevenueCat Shipaton, we wanted to prove that this could be more than an AI demo. We wanted Fork to feel like a real consumer mobile product with thoughtful design, a sustainable freemium model, and a premium experience users could actually understand.

What it does

Fork transforms a decision into a structured, visual exploration.

A user starts by describing something they are considering, such as:

"Should I buy a new laptop now or keep my current one for another year?"

Fork analyzes the context and creates several materially different paths.

Each path explains things such as:

immediate effects

potential benefits

tradeoffs

risks

assumptions

uncertainty

important variables

longer-term considerations

questions worth thinking about

Fork then lets the user move beyond reading an AI response.

They can visually explore the different branches, open individual scenarios, and compare paths across dimensions such as cost, time, flexibility, risk, effort, upside, short-term impact, and long-term impact.

Importantly, Fork does not generate a fake numerical score or declare one option the winner. The comparison is designed to make the differences visible while preserving the user's agency.

Users can save decisions to their Decision Journal and return to them later.

For monetization, we built Fork Pro with RevenueCat. The free experience lets people understand the core value of Fork, while the premium layer supports deeper and expanded exploration. RevenueCat manages the fork_pro entitlement and fork_pro_monthly subscription product, including offering retrieval, purchasing, entitlement state, and restoring purchases.

The result is a complete flow:

Describe → Analyze → Fork → Explore → Compare → Choose → Save

How we built it

Fork is built with React Native, Expo, and TypeScript, allowing us to create one mobile-first product architecture while also maintaining a testable web build.

The product is divided into three main layers: the client experience, AI analysis, and monetization.

AI and decision engine

When a user submits a decision, the mobile client does not expose an AI provider key.

Instead, the request goes to a Supabase Edge Function, which acts as our secure AI gateway.

Our architecture is:

Fork → Supabase Edge Function → AI provider → structured decision analysis → validation → Fork UI

The Edge Function takes the user's decision and optional context and asks the model to produce structured decision exploration rather than ordinary conversational text.

We defined a strict response structure covering scenarios, assumptions, tradeoffs, risks, uncertainty, comparison dimensions, questions, and branching information.

The returned data is validated before Fork uses it to construct the interface. This means the AI is not responsible for generating the UI itself; it produces structured decision data, and Fork deterministically renders that data into the product experience.

We initially integrated Anthropic Claude as our inference provider. During final testing, API credit limitations showed us why the AI layer should not depend on a single provider. We adapted the backend to support Google Gemini as an inference provider while preserving the same Fork schema and frontend contract.

That separation means the mobile application does not have to be rewritten when the inference provider changes.

RevenueCat

RevenueCat powers the monetization layer of Fork.

We created:

fork_pro_monthly as the monthly subscription product

fork_pro as the Pro entitlement

a RevenueCat offering containing the premium package

The app uses RevenueCat to retrieve the available offering, present the Pro experience, process test purchases, determine whether the user currently has the fork_pro entitlement, and restore previous purchases.

Rather than treating monetization as something added after the product was finished, we designed Fork's free and Pro experiences as part of the product architecture.

This was especially useful during Shipaton because RevenueCat allowed us to build and test the subscription lifecycle without creating our own purchase-state backend.

Product and interface

Fork's interface is designed around visual branching rather than chat.

The core experience includes:

decision creation

AI analysis states

visual scenario paths

scenario detail

qualitative comparison

decision journal/history

free/Pro boundaries

Fork Pro pricing and purchase experience

loading, empty, offline, and error states

We also built the experience with accessibility and failure states in mind, because an AI-powered consumer product needs to remain understandable even when a network or upstream AI provider is unavailable.

Challenges we ran into

One of our biggest challenges was making Fork feel like a decision product instead of another AI wrapper.

Getting an LLM to answer a question was the easy part. The harder problem was converting probabilistic model output into reliable structured data that a real interface could use.

We had to define strict schemas, validate responses, handle malformed output, and design the prompt so that generated paths were genuinely different rather than the same recommendation expressed three ways.

We also deliberately avoided having the model rank options or produce a single "best" answer. That forced us to think more carefully about how to represent uncertainty, tradeoffs, and comparison.

Deployment created another useful challenge. Our Expo web build is hosted through GitHub Pages, while analysis happens through a Supabase Edge Function. During production testing, we discovered differences between local and deployed environment configuration and a web connectivity check that could incorrectly interpret GitHub Pages behavior as the user being offline.

Tracking those issues across the browser, Expo, GitHub Actions, Supabase, and the AI provider taught us a lot about debugging a product across multiple services.

Finally, our original Anthropic integration hit an API credit limitation close to submission. Instead of coupling the entire application to that failure, we adapted the server-side inference layer so Gemini could power analysis while maintaining the same structured contract with the client.

That became one of the most valuable architectural lessons from building Fork.

Accomplishments that we're proud of

We're proud that Fork became more than a prompt connected to an API.

We built a complete decision-exploration system around the model output: structured scenarios, visual paths, assumptions, uncertainty, qualitative comparison, saved decisions, premium boundaries, and a subscription experience.

We're especially proud of preserving user agency as a product principle.

Fork does not pretend that AI can know the user's future. It does not generate fake probability percentages, assign arbitrary scores to someone's life choices, or tell the user which path they must take.

Instead, it helps make the structure of the decision visible.

We're also proud of the technical separation between our AI provider and the application. Being able to adapt the backend from Anthropic to Gemini without rebuilding Fork's core UI demonstrated why we designed the AI layer around a stable structured-data contract.

Finally, integrating RevenueCat turned Fork from a functional prototype into something much closer to a shippable consumer product. We implemented an actual entitlement model and premium experience rather than simply placing a disabled "Upgrade" button in the interface.

What we learned

The biggest lesson was that adding AI to a product is very different from designing a product around AI.

Model output is probabilistic. Interfaces cannot be.

We learned to place validation, schemas, constraints, fallbacks, and error handling between those two worlds.

We also learned that AI decision support works better when the model is treated as an exploration engine rather than an authority. Asking the model to expose assumptions and uncertainty produced a much more useful experience than simply asking it, "What should I do?"

RevenueCat taught us another side of product development: monetization is part of UX.

Entitlements, offerings, purchase state, restoration, loading states, and premium boundaries all affect how trustworthy and complete an application feels.

And finally, deploying Fork reinforced something every hackathon prototype eventually encounters:

The happy path is only the beginning.

A product becomes much more real when you start testing what happens when the network disappears, configuration is missing, an AI provider fails, a purchase is cancelled, or an external service becomes unavailable.

What's next for Fork

Our next goal is to evolve Fork from a single decision session into a longer-term decision intelligence companion.

We want users to be able to return to past decisions and record what actually happened. Over time, Fork could help people understand patterns in how they make decisions—not by judging those decisions, but by helping them reflect on the assumptions they made and how reality differed.

We also want to expand the branching engine so users can explore deeper second-order paths: not only "What happens if I choose A?" but "If I choose A and this assumption changes three months later, what options remain?"

On the engineering side, our provider-independent AI architecture gives us room to improve model routing, reliability, latency, and cost without coupling those decisions to the mobile client.

For RevenueCat, we want to continue refining Fork Pro around features that genuinely benefit from recurring value, such as deeper explorations, expanded decision history, advanced branching, and richer reflection tools.

The long-term vision remains intentionally simple:

Fork should never make the decision for you.

It should give you a clearer map of the paths in front of you so that you can make the decision yourself.

Built With

Share this project:

Updates

Submission history