Pitchdeck: https://canva.link/nzw6jy5gj0zzfh6

Inspiration

RARELY — BE MORE YOU was inspired by a simple observation: modern digital products often make self-expression feel like a competition.

Social platforms encourage comparison. Productivity apps encourage optimization. Recommendation systems often tell people what is trending, what everyone else is doing, or what they should be interested in. Even creative tools can become overwhelming because they give users endless possibilities without giving them a meaningful starting point.

RARELY was designed around a different question:

What if technology helped you become more yourself instead of becoming more like everyone else?

That idea became the foundation for the entire product.

RARELY is built around small moments of self-discovery rather than endless consumption. Instead of opening the app to scroll through a feed, the experience begins by asking:

“How are you feeling today?”

That question is intentionally simple. There is no right answer, no score, no productivity metric, and no pressure to perform. The user's mood becomes the starting point for a personalized experience.

From there, RARELY can suggest a Rare Moment: a small activity designed around the user's current emotional state. A creative mood might lead to writing a line beginning with “I wonder…”. A stressed mood might lead to a calming ritual. A tired mood might lead toward something gentle and low-pressure.

This philosophy also influenced the visual identity.

The brand system was designed around an abstract R that feels simultaneously like a letter, a path, an orbit, and a moment of transformation. The symbol is intentionally open rather than closed. It suggests that identity is something people explore rather than something that is predetermined.

The visual language combines:

• warm ivory backgrounds;
• deep plum typography;
• soft coral accents;
• restrained lavender;
• subtle blush;
• editorial typography;
• generous negative space;
• rounded, tactile UI elements.

The goal was to create something that feels emotionally intelligent without looking clinical, and technologically sophisticated without looking like another generic AI startup.

The central brand statement became:

Less comparison. More you.

Everything in the product is ultimately connected to that sentence.

The inspiration was not to build another social application, another journaling application, or another AI chatbot.

It was to create a new category of digital space:

an intelligent personal-expression operating system.

---

What it does

RARELY is a personalized mobile experience for self-expression, creativity, reflection, discovery, and positive community.

The product brings together several experiences that are usually separated across different apps.

Mood-based discovery

The Home screen begins with a mood check-in.

Users can select from moods such as:

• ☀️ Happy
• 🌧️ Stressed
• ✨ Creative
• 🌙 Tired
• ⚡ Excited
• 🪩 Just vibing

The selected mood influences the Rare Moment recommendation shown on screen.

The experience avoids treating mood as a diagnosis or measurement. It is simply a lightweight way of helping the application understand what kind of interaction may feel appropriate right now.

For example:

Creative → Make a little magic

The app can then suggest a short sequence of activities that can be completed without preparation:

1. Write a line that starts with “I wonder…”
2. Take a photo of an interesting color.
3. Save one idea for later.

The entire activity is framed around:

10 minutes. No pressure.

That constraint is intentional. RARELY is designed to make creativity feel approachable.

---

Rare Moments

Rare Moments are the heart of the experience.

Rather than giving users an enormous library of activities, the product surfaces a focused recommendation that feels relevant to the current moment.

A Rare Moment contains:

• a title;
• a short explanation;
• a visual atmosphere;
• a reason for the recommendation;
• a small number of steps;
• a completion action;
• recommendation feedback.

One of the most important UX details is the “Why this was suggested” explanation.

Instead of presenting personalization as invisible magic, RARELY gives users a simple explanation such as:

“A creative moment shaped around your creativity, with room to make it your own.”

This establishes a more transparent relationship between the user and the recommendation system.

---

Creative tools

The Create section gives users several ways to express themselves.

Current creative directions include:

Journal

A private writing experience for thoughts, reflections, and daily prompts.

Photo Prompt

A lightweight visual observation exercise encouraging the user to notice something around them.

Music Mood

A mood-driven music reflection activity that connects songs with emotions and memories.

Collage

A visual composition activity built around colors, textures, and small personal discoveries.

Rare AI

An AI-assisted creative experience designed to generate ideas rather than replace the user's creativity.

Sponsor Studio

A product-oriented space demonstrating how branded creative experiences can eventually fit into the ecosystem without turning the product into an advertising-first platform.

---

Journaling

RARELY includes a private journaling workflow with support for:

• prompts;
• draft persistence;
• editing;
• deletion;
• recovery;
• local image references;
• export/sharing;
• privacy controls.

A major design decision was to treat journaling as a private-first experience.

The application does not need to send every personal thought to a cloud backend in order to provide value.

The journal persistence layer is deliberately defensive. It can distinguish between states such as:

empty
loaded
malformed
unavailable

That means a corrupted or unavailable storage layer does not automatically become a destructive action.

The philosophy is:

A temporary storage problem should never become a permanent loss of someone's thoughts.

---

Personalization

Personalization is one of the most technically important parts of RARELY.

Instead of immediately building a heavy machine-learning recommendation system, the product uses a transparent local recommendation model.

The system can consider:

• selected interests;
• journal activity;
• saved Rare Moments;
• joined circles;
• completed routines;
• recent activity;
• explicit recommendation feedback.

Users can also say:

This fits

or

Not for me

Those signals influence future ordering.

This makes the recommendation model:

• explainable;
• deterministic;
• testable;
• lightweight;
• privacy-conscious;
• easy to improve.

RARELY is therefore not trying to predict who a person is.

It is trying to remember what they have explicitly shown interest in.

---

Community

Community is structured around smaller positive circles rather than a traditional infinite social feed.

Current examples include:

Make Room for Ideas

A space centered around curiosity and creative exploration.

Soft Confidence

A space focused on confidence, self-recognition, and personal growth.

The Listening Room

A space centered around music and emotional atmosphere.

The goal is to create social interaction without reproducing the pressure dynamics of mainstream social media.

Community participation is therefore treated as an intentional action rather than another metric to maximize.

---

Rare Studio

Rare Studio provides recurring rituals and creative routines.

Examples include:

• Soft Focus;
• Color Play;
• The Reset.

These experiences allow RARELY to move beyond one-off recommendations and toward repeatable rituals.

A user might discover a five-minute activity on Monday and gradually develop a personal relationship with that ritual over time.

---

Profile and Scrapbook

The Profile experience turns individual interactions into a personal history.

Users can see activity such as:

• thoughts kept;
• Rare Moments completed;
• circles joined;
• rituals completed.

The Scrapbook takes this further by presenting a chronological, private timeline of activity.

The concept is important:

RARELY is not simply a place where things happen. It becomes a record of who the user is becoming.

---

How we built it

RARELY was built as a modern cross-platform application using an architecture designed to keep the mobile experience fast while maintaining a clean path toward a larger backend.

Technology stack

The core stack includes:

• React Native
• Expo
• TypeScript
• Expo Router
• React Query
• tRPC
• SuperJSON
• Zod
• Express
• Drizzle ORM
• MySQL
• AsyncStorage
• Vitest
• esbuild

The project uses pnpm as its package manager.

The application targets mobile-first interaction while also supporting a web runtime through Expo/Metro.

---

Architecture

The architecture separates UI, local UX state, typed API communication, and server functionality.

flowchart TD
    USER[User]

    subgraph MOBILE[RARELY Mobile Client]
        ROUTER[Expo Router]
        SCREENS[React Native Screens]
        UX[UX Domain Modules]
        LOCAL[Local Persistence]
        TRPC_CLIENT[tRPC Client]
    end

    subgraph SERVER[Application Server]
        EXPRESS[Express]
        TRPC_SERVER[tRPC]
        AUTH[Authentication]
        AI[AI Services]
        STORAGE[Media / Storage]
        DB[Drizzle + MySQL]
    end

    USER --> ROUTER
    ROUTER --> SCREENS
    SCREENS --> UX
    UX --> LOCAL
    SCREENS --> TRPC_CLIENT

    TRPC_CLIENT --> EXPRESS
    EXPRESS --> TRPC_SERVER
    TRPC_SERVER --> AUTH
    TRPC_SERVER --> AI
    TRPC_SERVER --> STORAGE
    TRPC_SERVER --> DB

One of the strongest architectural decisions was separating product behavior from individual screens.

Instead of embedding recommendation logic directly in Home, for example, the repository contains reusable modules for:

• personalization;
• AI safety;
• journal persistence;
• activity normalization;
• monetization;
• motion behavior;
• local reset;
• route guards;
• haptics.

This makes the product easier to extend without duplicating business logic.

---

Navigation

The core navigation consists of five primary surfaces:

Home
Create
Community
Studio
Profile

Each surface has a clear role.

The app also contains dedicated routes for:

Rare Moment
Journal
Circle
Routine
Scrapbook
Preferences
Membership
AI History
OAuth Callback

The root layout provides the shared application infrastructure, including:

• React Query;
• tRPC;
• safe-area support;
• gestures;
• theme handling;
• error boundaries;
• navigation;
• authentication/session behavior.

---

Local-first state

One of the defining technical choices was keeping a significant amount of product state on-device.

Local state includes concepts such as:

• last selected mood;
• preferences;
• journal drafts;
• journal entries;
• activity history;
• recommendation feedback;
• AI prompt history;
• monetization UX state.

This means many experiences can continue functioning without a network connection.

The architecture can be summarized as:

flowchart LR
    APP[RARELY App]

    APP --> LOCAL[Local Product Memory]
    APP --> API[Typed API]

    LOCAL --> JOURNAL[Private Journals]
    LOCAL --> ACTIVITY[Activity History]
    LOCAL --> PREF[Preferences]
    LOCAL --> FEEDBACK[Recommendation Feedback]

    API --> AUTH[Authentication]
    API --> AI[Creative AI]
    API --> DB[(MySQL)]

The server exists where server-side infrastructure provides real value.

The device remains the primary home for personal creative state.

---

Typed APIs

The project uses tRPC to create a strongly typed boundary between client and server.

Instead of manually maintaining separate API request and response types, the client consumes the server's router types.

That provides a workflow closer to:

TypeScript UI
     ↓
typed procedure
     ↓
server procedure
     ↓
validated response

This dramatically reduces an entire class of mismatched API contracts.

---

Validation with Zod

Zod is used around server-side inputs and AI output structures.

That is especially important because AI output is fundamentally untrusted application input.

For structured creative generation, the server validates constraints such as:

• title length;
• summary length;
• exact number of lines;
• line length;
• palette structure;
• valid hexadecimal colors.

This ensures the application does not blindly trust model output.

---

AI implementation

AI was intentionally implemented as a creative tool, not an always-on assistant.

The AI system uses explicit modes including:

Spark
Reflect
Play

Those modes help constrain what the user should expect.

Before an AI request is made, the application can:

1. require consent;
2. inspect input for secret-like content;
3. minimize contextual data;
4. enforce input length limits;
5. send the request through the controlled server route;
6. validate returned output;
7. fall back to deterministic content when necessary.

The conceptual pipeline is:

flowchart TD
    INPUT[User Input]
    CONSENT{Explicit Consent?}
    CHECK[Privacy / Secret Check]
    MIN[Context Minimization]
    LIMIT{Within Limits?}
    SERVER[Server AI Procedure]
    VALIDATE[Output Validation]
    FALLBACK[Deterministic Fallback]
    RESULT[Creative Result]

    INPUT --> CONSENT

    CONSENT -- No --> FALLBACK
    CONSENT -- Yes --> CHECK

    CHECK --> MIN
    MIN --> LIMIT

    LIMIT -- No --> FALLBACK
    LIMIT -- Yes --> SERVER

    SERVER --> VALIDATE

    VALIDATE -- Invalid --> FALLBACK
    VALIDATE -- Valid --> RESULT

This makes AI a controlled dependency instead of allowing it to dictate the application's behavior.

---

Technical diagrams and product architecture

Another important part of building RARELY was understanding that the product needed to communicate itself visually.

The logo system, product UI, architecture diagrams, and brand presentation all revolve around the same principles:

simplicity on the surface, sophistication underneath.

The final brand identity translates that philosophy into a visual language:

             R
          ↗  │  ↘
       identity
           ↓
     personalization
           ↓
       discovery
           ↓
       self-expression

The abstract R symbol represents a path rather than a static object.

That same concept appears inside the application architecture: the user enters with a mood, receives a personalized starting point, creates something, reflects on it, and builds a growing personal history.

---

Challenges we ran into

Building RARELY required solving several problems that are easy to underestimate.

1. Building personalization without overengineering it

One of the biggest challenges was deciding how “smart” personalization needed to be.

It would have been possible to immediately introduce a large recommendation infrastructure or machine-learning pipeline.

But doing that would have created several problems:

• higher infrastructure complexity;
• greater privacy concerns;
• harder debugging;
• less predictable behavior;
• difficult-to-explain recommendations;
• more data collection than the early product actually needs.

Instead, RARELY uses a lightweight scoring model.

The challenge was finding the right balance between:

“This feels personalized.”

and

“We are not pretending we know everything about you.”

That led to explicit feedback, recency weighting, confidence scoring, and controlled exploration.

---

2. Making AI useful without making it invasive

AI creates a particularly difficult product problem for a personal-expression application.

Journal entries can be deeply personal.

If the product uses private journal content as AI context, the experience may become more powerful—but it also becomes significantly more invasive.

RARELY took the opposite direction.

The AI system is governed by explicit rules designed to minimize unnecessary context.

That meant building safeguards around:

• consent;
• context minimization;
• secret-like data detection;
• output limits;
• prompt governance;
• validation;
• deterministic fallbacks.

The challenge was not simply getting AI to generate something.

The challenge was building an AI feature that users can trust.

---

3. Making local persistence reliable

Local-first applications create a different category of edge cases.

Network-backed applications often fail loudly when an API request breaks.

Local applications can fail quietly.

Storage can be:

• unavailable;
• malformed;
• incomplete;
• interrupted;
• out of sync with a newer application version.

Journaling made this especially important because the data is valuable and emotionally meaningful.

That resulted in defensive parsing, explicit storage states, recovery behavior, and careful cleanup semantics.

---

4. Designing for failure without making the app feel broken

Another challenge was designing degraded states that still feel intentional.

For example, if recommendation data is unavailable, the application should not suddenly become unusable.

Instead, it can fall back to curated local content.

The broader pattern became:

full experience
      ↓
partial recovery
      ↓
local fallback
      ↓
useful empty state
      ↓
clear retry path

That philosophy was applied across AI, persistence, recommendation, and optional native functionality.

---

5. Combining premium design with technical transparency

RARELY needed to feel sophisticated, but not overly complicated.

The design had to support:

• premium visual identity;
• emotional warmth;
• AI sophistication;
• technical credibility;
• accessibility;
• mobile usability.

Too much decoration would make the experience feel like a lifestyle brand.

Too much technical styling would make it look like another AI startup.

The final design direction sits between the two:

editorial + technological + human.

---

6. Making personalization explainable

A recommendation system becomes uncomfortable when users do not understand why they are seeing something.

That is why RARELY includes explanations such as:

Why this was suggested

instead of simply presenting a recommendation with no context.

This created another challenge: the explanation had to be useful without exposing private information or revealing internal scoring calculations.

The result is a deliberately high-level explanation layer.

---

7. Keeping interactions reversible

Another recurring challenge was deciding what happens after an action.

Joining a circle, completing a routine, dismissing a recommendation, or deleting a journal entry should not always feel permanent.

That led to a recurring product principle:

Whenever possible, user actions should be reversible.

Undo flows, editable state, recoverable drafts, reset functionality, and feedback changes are all expressions of that principle.

---

Accomplishments that we're proud of

One of the biggest accomplishments is that RARELY has evolved beyond a collection of screens into a coherent product system.

A real product loop exists

The application has a recognizable behavioral cycle:

flowchart TD
    MOOD[Check in]
    RECOMMEND[Receive personalized moment]
    CREATE[Create / reflect]
    SAVE[Save activity]
    FEEDBACK[Give feedback]
    PERSONALIZE[Improve future recommendations]

    MOOD --> RECOMMEND
    RECOMMEND --> CREATE
    CREATE --> SAVE
    SAVE --> FEEDBACK
    FEEDBACK --> PERSONALIZE
    PERSONALIZE --> MOOD

That loop is small enough to understand but powerful enough to expand.

---

We built a real personalization foundation

The recommendation system already supports:

• multiple domains;
• explicit positive feedback;
• explicit negative feedback;
• recency;
• confidence;
• exploration;
• explanations;
• personalization reset.

That is a stronger foundation than simply shuffling cards.

---

We treated privacy as product architecture

Privacy was not added as a footer or settings page.

It affects how:

• journals are persisted;
• AI requests are constructed;
• activity is displayed;
• private notes are previewed;
• user state is stored;
• AI history is maintained.

That is something we are particularly proud of because privacy is easy to promise and much harder to engineer.

---

We created graceful AI behavior

A common failure mode for AI applications is:

Model unavailable → feature broken.

RARELY instead follows:

Model unavailable → useful creative fallback.

That makes the product less dependent on an external model provider and gives the experience a consistent personality even when AI services fail.

---

We created a strong visual identity

The final RARELY identity connects the product's emotional concept with its technology positioning.

The abstract R symbol combines:

• identity;
• orbit;
• transformation;
• discovery;
• movement;
• individuality.

The wordmark and slogan create a system that works across:

• app icons;
• mobile interfaces;
• presentations;
• brand collateral;
• web experiences;
• social media;
• future merchandise.

The result feels like a complete brand instead of simply an application name.

---

We built accessibility into interactions

Accessibility considerations include:

• meaningful labels;
• button semantics;
• selected-state semantics;
• safe-area handling;
• reduced-motion behavior;
• readable text hierarchy;
• fallback context when imagery fails.

This is important because RARELY is meant to be an intimate, everyday product.

An interaction that is uncomfortable or inaccessible quickly becomes an interaction people stop using.

---

We established a strong technical foundation

The repository now has clear boundaries between:

UI
↓
UX behavior
↓
local state
↓
typed API
↓
server procedures
↓
database / AI / storage

That structure makes it much easier to scale the product without turning every screen into a monolithic component.

---

What we learned

1. A simple product can require sophisticated engineering

The user experience of RARELY is deliberately simple.

Select a mood.

Choose a moment.

Make something.

Save it.

But underneath that simplicity are problems involving:

• state management;
• persistence;
• personalization;
• AI governance;
• accessibility;
• authentication;
• networking;
• database design;
• error handling;
• monetization.

This reinforced an important lesson:

Simplicity for the user often requires complexity behind the scenes.

---

2. Not every personalization problem needs machine learning

A transparent rule-based recommendation system can provide a surprisingly strong personalized experience.

The important part is not the sophistication of the algorithm.

It is whether the recommendation feels:

• relevant;
• timely;
• explainable;
• respectful.

For an early-stage product, deterministic personalization can therefore be an advantage.

It provides a stable foundation that can later evolve into more advanced models once there is enough validated product behavior to justify them.

---

3. Privacy can improve the product experience

Privacy initially appears to be a limitation.

For example:

“Don't use private journal text as AI context.”

That sounds like less information for the AI.

But it also forces the product to become more intentional.

Instead of relying on unrestricted access to personal information, RARELY has to generate value from:

• explicit preferences;
• current mood;
• short creative instructions;
• interaction history;
• deliberate user feedback.

That creates a healthier boundary between personalization and surveillance.

---

4. Fallbacks are part of the product

A fallback should not feel like an engineering apology.

If AI fails, a creative prompt can still be useful.

If personalization fails, curated content can still be valuable.

If an optional capability is unavailable, the rest of the interface can remain functional.

This changed the way we think about reliability.

Reliability is not simply:

“The service never fails.”

Reliability is:

“The user can still accomplish something meaningful when part of the system fails.”

---

5. Explainability builds trust

A small label such as:

Why this was suggested

has a disproportionate impact.

It communicates that recommendations are not arbitrary.

The same philosophy should apply to AI, monetization, notifications, and personalization.

People should understand:

what happened, why it happened, and what they can change.

---

6. Emotional products still need rigorous engineering

It is tempting to assume that an application centered around feelings, creativity, journaling, and aesthetics can succeed primarily through design.

But emotional products are especially sensitive to technical quality.

A lost journal entry is worse than a lost shopping cart.

An inappropriate AI recommendation can feel more invasive than an incorrect product suggestion.

A notification at the wrong moment can undermine the entire tone of the product.

That means emotional intelligence in product design has to be supported by engineering discipline.

---

7. The best product metric may not be engagement

Traditional social products optimize for:

• time spent;
• sessions;
• clicks;
• scrolling;
• daily active users.

RARELY points toward a different philosophy.

A successful interaction might be:

User opened the app, completed a five-minute ritual, wrote something meaningful, and left.

That could be a better outcome than having the user spend forty-five minutes scrolling.

This changes how the product should eventually measure success.

The goal is not:

more time in RARELY.

The goal is:

more meaningful time because of RARELY.

---

What's next for RARELY: BE MORE YOU

RARELY already has the foundation of the experience.

The next phase is about turning that foundation into a durable, scalable product while protecting the qualities that make it different.

1. Multi-device synchronization

The strongest next technical step is a privacy-conscious synchronization system.

The goal should not be:

Upload everything to the cloud.

Instead:

Let users choose what deserves continuity across devices.

A future synchronization architecture could look like:

flowchart LR
    PHONE[Phone]
    LOCAL[Local-first state]
    OUTBOX[Encrypted / controlled sync queue]
    API[Sync API]
    DB[(Cloud Data)]
    MERGE[Conflict Resolution]
    TABLET[Second Device]
    WEB[Web]

    PHONE --> LOCAL
    LOCAL --> OUTBOX
    OUTBOX --> API
    API --> DB
    DB --> MERGE
    MERGE --> TABLET
    MERGE --> WEB

Private journal content should remain opt-in.

---

2. A richer personal memory system

RARELY could eventually develop a more sophisticated personal memory layer.

Instead of simply knowing:

“You like creativity.”

It could understand patterns such as:

“You tend to create more when you have short, low-pressure prompts.”

or:

“You often save visual ideas in the evening.”

The important distinction is that this intelligence should still be transparent and user-controlled.

A future system could allow users to see:

What RARELY remembers about me

and edit or remove individual memories.

---

3. More sophisticated recommendations

The existing deterministic recommendation system provides the foundation for a future hybrid recommendation engine.

Potential progression:

Stage 1
Explicit preferences
        ↓
Stage 2
Feedback + recency
        ↓
Stage 3
Behavioral patterns
        ↓
Stage 4
Contextual recommendations
        ↓
Stage 5
Personalized recommendation models

Each stage should preserve the ability to explain and reset personalization.

---

4. AI creative companion

Rare AI can eventually evolve beyond simple prompt generation.

A future version could support:

• creative brainstorming;
• visual concept generation;
• writing prompts;
• moodboards;
• personalized creative challenges;
• remixing ideas;
• guided reflection.

But the core rule should stay the same:

AI should amplify the user's voice, not replace it.

---

5. More community experiences

Community could eventually evolve into:

• smaller private circles;
• interest-based groups;
• moderated creative rooms;
• shared challenges;
• collaborative prompts;
• collaborative moodboards;
• positive rituals.

But community growth should not automatically mean introducing the mechanics of traditional social media.

RARELY should remain intentionally different from an infinite feed.

---

6. Better creative capture

Future versions could make it even easier to turn everyday life into material for self-expression.

Potential experiences include:

camera
  ↓
notice
  ↓
describe
  ↓
reflect
  ↓
create
  ↓
save

A photograph could become a journal prompt.

A song could become a memory.

A color could become a collage.

A thought could become a creative challenge.

The product opportunity is to connect these small moments without making them feel like work.

---

7. Deeper personalization without deeper surveillance

This is perhaps the most important long-term challenge.

RARELY should become smarter without becoming invasive.

That means exploring technologies such as:

• on-device inference;
• privacy-preserving embeddings;
• user-visible memory controls;
• selective synchronization;
• ephemeral AI context;
• aggregated analytics;
• differential or privacy-preserving telemetry where appropriate.

The long-term goal is:

More intelligence with less unnecessary data.

---

8. Membership and sustainable business model

The existing monetization architecture creates a foundation for a future membership system.

Potential premium capabilities could include:

• advanced creative tools;
• expanded AI usage;
• deeper personal rituals;
• premium visual experiences;
• enhanced scrapbook features;
• advanced personalization;
• exclusive creative programs.

The monetization philosophy should remain consistent:

RARELY should earn trust before asking for money.

The user should never feel that an emotional moment is being deliberately engineered into a sales funnel.

---

9. Brand expansion

The RARELY identity has the potential to extend beyond the application.

The abstract R symbol can become:

• a recognizable app icon;
• a social avatar;
• an animation system;
• a loading state;
• a subtle UI motif;
• physical merchandise;
• editorial graphics;
• digital experiences;
• future wellness/creative products.

The visual identity should grow with the product without becoming decorative noise.

---

10. Measuring meaningful outcomes

The long-term analytics philosophy should move beyond conventional engagement.

Potential product health indicators include:

Creative completion

Are users actually completing small creative experiences?

Reflection quality

Are users returning to journaling or reflective activities?

Positive recommendation feedback

Are recommendations becoming more relevant over time?

Healthy session patterns

Can users receive value without being trapped in endless scrolling?

Retention through usefulness

Do people return because the product genuinely helps them express themselves?

The north-star philosophy could ultimately be:

How many meaningful moments did RARELY help someone create?

---

The future of RARELY

RARELY began with a simple idea:

Less comparison. More you.

The technology exists to make the internet increasingly personalized.

The harder question is:

What should that personalization be for?

RARELY's answer is not more scrolling.

It is not more content.

It is not more optimization.

It is more self-expression, more discovery, more creativity, and more intentional connection with yourself.

The product is designed to meet someone where they are:

How are you feeling today?

Then give them one small next step.

Maybe it is writing.

Maybe it is taking a photograph.

Maybe it is listening to a song.

Maybe it is joining a circle.

Maybe it is doing absolutely nothing demanding.

The important thing is that the product does not tell the user who to become.

It creates room for them to discover it.

That is the idea behind the name.

That is the idea behind the product.

That is the idea behind the visual identity.

And ultimately, that is what RARELY — BE MORE YOU is trying to build:

A technology platform that helps people become more themselves, not more like everyone else.

Built With

• react-native