Crush

Introduction

The Crush project is a privacy-first "Secret Crush" mobile application designed to allow users to add target phone numbers from their mobile contacts to a restricted "Crush List." A match is revealed only when interest is strictly bidirectional and mutual, ensuring absolute anonymity until a mutual match occurs. This document outlines the system requirements for the Crush application, focusing on simplicity and a clean user interface.

System Overview

Crush is a mobile application that operates on a serverless architecture using Firebase Firestore for database management. The app's primary goal is to maintain user privacy while facilitating mutual connections. The system is designed to operate with minimal operational costs, leveraging Firebase's free tier services and efficient data handling strategies.

Functional Requirements

• As a User, I should be able to add phone numbers from my contacts to a "Crush List."
• As a User, I should only be notified of a match when the interest is mutual.
• As a User, I should have a clean and intuitive onboarding experience with phone number input and Reverse-SMS verification.
• As a User, I should be able to view my active crush slots in a scannable grid format.
• As a User, I should be able to add crushes using a contact list picker or manual dialer with duplication warnings.
• As a User, I should be able to view my match history in a chronological order with infinite scroll for archived matches.
• As a User, I should be able to upgrade my account to increase my crush list capacity.
• As a User, I should not receive notifications for unmatched crushes to maintain privacy.
• As a User, I should be able to manually unmatch a previously matched number.

User Personas

• Regular User: A person using the app to add and manage crushes, view matches, and upgrade their account.
• Pro User: A user who has upgraded to the Pro Tier for increased crush list capacity.
• Elite User: A high-volume user with the Elite Tier, managing a large number of crushes.

Core User Flows

1. Onboarding Flow: User enters phone number -> Receives Reverse-SMS prompt -> Completes verification -> Accesses dashboard.
2. Adding a Crush: User selects contact -> Checks for duplicates -> Adds to crush list -> System checks for mutual match.
3. Match Notification: Mutual match detected -> Both users receive a notification -> Match added to history.
4. Viewing Match History: User accesses match history -> Scrolls through recent matches -> Fetches archived matches as needed.
5. Upgrading Account: User selects upgrade option -> Completes payment -> Crush list capacity increases.

Visuals Colors and Theme

• primary: #4A90E2 (a calm blue for a modern look)
• primary_light: #B3D4FC (a lighter tint of primary for hover states)
• secondary: #FF6F61 (a contrasting coral for emphasis)
• accent: #FFD700 (a vibrant gold for CTAs and active states)
• highlight: #FFA500 (a warm orange for notifications)
• bg: #F5F5F5 (a soft grey for the background)
• surface: rgba(255, 255, 255, 0.9) (a subtle white for cards/panels)
• text: #333333 (a dark grey for primary text)
• text_muted: #777777 (a softer grey for secondary text)
• border: rgba(0, 0, 0, 0.1) (a light grey for borders)

Signature Design Concept

The Crush app will feature a unique "Crush Galaxy" interactive homepage. Users will navigate a 3D galaxy where each star represents a potential crush. Clicking a star will reveal more information about the crush, and dragging will rotate the galaxy to explore more options. This interactive experience will be built using @react-three/fiber for 3D rendering and gsap for smooth animations and transitions. The galaxy will subtly change colors based on the time of day, providing a dynamic and engaging user experience.

Interaction Model & Motion Direction

The landing page will utilize a "parallax" interaction model, creating a layered depth effect as users scroll through the app. Decorative elements will move at different speeds, enhancing the storytelling aspect of the app. Internal pages will maintain a "static" interaction model to prioritize clarity and readability, especially for data-heavy sections like the dashboard and match history.

Non-Functional Requirements

• The application must operate on a serverless architecture to minimize costs.
• The system should ensure data privacy and security, especially concerning user contact information.
• The app should be scalable to accommodate a growing user base without performance degradation.

Tech Stack

• Frontend: React Native for mobile app development.
• Backend: Firebase Cloud Functions for serverless operations.
• Database: Firebase Firestore for NoSQL data management.
• Authentication: Firebase Authentication with Reverse-SMS verification.
• Monetization: RevenueCat for managing subscription tiers.

Assumptions and Constraints

• The app will initially target users in India, considering local carrier support for SMS verification.
• The system must adhere to Firebase's free tier constraints to maintain a low operational budget.
• User privacy is paramount, and no data should be shared without explicit mutual consent.

Glossary

• Crush List: A list of phone numbers added by the user, representing potential romantic interests.
• Match History: A record of mutual matches between users.
• Reverse-SMS Verification: A method of verifying user identity by sending a pre-filled SMS from the user's device.
• RevenueCat: A platform for managing in-app subscriptions and purchases.