SquadSesh

SquadSesh is a cross-platform mobile application for coordinating gaming sessions among friend groups. It provides group management, availability scheduling, session RSVPs with real-time push notifications, a social friend system, and an in-app economy with cosmetic customization. The project was designed, built, and operated end-to-end as a solo developer effort under E2E Automation.

- Architecture
The system follows a client-server architecture with a RESTful API layer. The backend is built on Django with Django REST Framework, backed by PostgreSQL and Redis for caching and task queue brokering. Asynchronous work, push notification fan-out, email dispatch, and debounced notifications all handled by Celery. The API is served through an ASGI stack.
The Flutter frontend uses the Provider pattern for state management and communicates with the backend through authenticated REST endpoints under a versioned API namespace. Firebase provides the push notification transport layer, crash reporting, and device token management. User-uploaded media is stored in AWS S3.

- Core Feature Areas
The scheduling system supports both one-off and recurring availability slots, with group-level availability aggregation that lets members visualize overlap across their squad. Gaming sessions are tied to groups with per-participant RSVP tracking and debounced notifications to prevent spam when users rapidly change their status.
The notification subsystem includes persistent server-side records with type classification (friend requests, group invites, RSVP updates, session events, admin actions), cached unread counts, and cache invalidation across all mutating actions. The Flutter client implements an optimistic update with rollback pattern for all notification state changes to keep the UI responsive while remaining consistent with server state.
The social layer includes friend requests with bidirectional filtering — the user search endpoint excludes existing friends, pending requests in both directions, and the querying user themselves, all enforced at the query level.

- In-App Economy and Monetization
SquadSesh includes a virtual currency system (Sesh Coins) with admin-configurable reward rules per action type (RSVP responses, session creation, rewarded ad views, weekly streaks). Coin balances are maintained as denormalized running totals updated atomically alongside every transaction. A cosmetic shop allows users to spend coins on themes, profile frames, fonts, and ring colors, with access tiers computed server-side and exposed through a dedicated endpoint.
Monetization is handled through platform-native billing (Google Play Billing with Apple App Store support scaffolded) for one-time purchases: ad removal, a premium tier, a premium upgrade path, and a consumable tip. The backend is the sole source of truth for entitlement state — the Flutter client syncs from the server on login and initialization rather than trusting local purchase state. Interstitial ads are served through AdMob with cooldown enforcement, while rewarded ads remain available to all users including premium.

- Infrastructure and Operations
The application runs separate staging and production environments with transactional email delivery via Mailgun. Django settings are split across environment-specific configurations.
Load testing is implemented with Locust, modeling realistic user behavior through weighted task distributions — high-frequency dashboard check-ins, medium-frequency group browsing, and low-frequency session creation — with a configurable read-only mode for safe production testing. The test suite includes composite user flows that chain multiple API calls to simulate real navigation patterns.

- Key Technical Decisions
Several architectural decisions emerged from production debugging. ASGI workers proved incompatible with Django's persistent database connection settings, causing pool exhaustion under load — connection pooling was deferred to a dedicated pooling layer. DRF's read_only serializer fields silently drop values from validated_data, requiring explicit handling in perform_create overrides. Celery's default process pool exceeded memory limits on the hosting tier, requiring tuning for the available resources. Membership-filtered querysets in DRF viewsets required careful bypass for endpoints that operate on resources the requesting user doesn't yet belong to, such as accepting group invitations.

- Technologies
Backend: Django, Django REST Framework, PostgreSQL, Redis, Celery, AWS S3, Firebase Admin SDK, Mailgun. Frontend: Flutter, Google Mobile Ads, In-App Purchase, Firebase Messaging, Crashlytics. Testing: Locust. Design: Canva.