Skip to content
←Return to Projects
Case Study

Payday Chat

A real-time, members-only network for online business founders.

The Problem

Founders needed a private, high-signal place to network, build teams, and scale revenue — not another noisy public feed. Payday Chat is invite-only and built around real-time collaboration.

My Role

Built solo with AI-assisted development — Flutter client, NestJS API, data model, real-time layer, and deployment.

Visit Platform ↗

Highlights

  • Real-time messaging with presence and live events over WebSockets
  • One NestJS API powering both a Flutter mobile app and a web client
  • PostgreSQL domain model with Redis for caching and pub/sub fan-out
  • NGINX gateway, Stripe payments, and OAuth authentication

Stack

FlutterDartNestJSPostgreSQLRedisNGINXStripe

Constraints

  • Invite-only product — auth and access control had to be correct from day one.
  • One backend, two clients (Flutter + web) — schema and contracts had to be shared, not duplicated.
  • Realtime is a feature, not a nice-to-have — presence and live events must survive reconnects.

System Architecture

Clients
Flutter Mobile App
Web App
Gateway
NGINX
API
NestJS REST
WebSocket Gateway
Data
PostgreSQL
Redis (cache + pub/sub)
External
Stripe
OAuth

Key Trade-offs

The decisions worth defending — what I chose, what I turned down, and why.

Realtime transport

Chose

WebSockets with Redis pub/sub fan-out

Rejected

Long-polling or third-party realtime SaaS

Predictable latency, no per-message vendor cost, and Redis already in the stack for caching — one fewer moving part.

Mobile client framework

Chose

Flutter (single codebase for iOS + Android)

Rejected

Native Swift + Kotlin clients

Solo build — two native clients would have doubled the surface area and slowed iteration on the API.

API style

Chose

REST + dedicated WebSocket gateway

Rejected

GraphQL subscriptions

Simpler operational story, easier to cache at the NGINX layer, and the realtime channel stays an explicit, observable component.

What I'd Do Differently

An honest retrospective — the stuff I'd change with more time, more users, or a second pass.

  1. 1Introduce contract tests between the NestJS API and the Flutter client earlier — a few breakages were caught only at runtime.
  2. 2Move long-lived sockets to a dedicated process so API deploys don't drop client connections.
  3. 3Add structured event versioning from day one instead of retrofitting it once the schema started moving.

Technical Deep-Dive

Architecture, specifications, and implementation details.

Android Deployment Steps for Payday Chat

#1. Update Allowed Origins for Mobile

  • Edit server/.env and add your Android device's IP to ALLOWED_ORIGINS:
    • Example: ALLOWED_ORIGINS=http://localhost:3001,http://localhost:3000,http://192.168.1.100
  • Restart the API container:
    • docker restart payday-api

#2. Build and Deploy the Android App

  • From the mobile/ directory:
    • Run flutter clean
    • Run flutter pub get
    • Run flutter build apk (or flutter build appbundle for Play Store)
  • Install the APK on your device:
    • adb install build/app/outputs/flutter-apk/app-release.apk

#3. Configure Mobile App API URL

  • Ensure the mobile app points to your backend API (LAN IP, not localhost):
    • Example: http://192.168.1.10:3000/api/v1
  • Update any .env or config files in mobile/lib/config/ as needed.

#4. Test Registration, Login, OAuth, and Health

  • Register and log in from the Android app.
  • Test Google/Apple OAuth (device must have browser access).
  • Check health endpoint from the app (should return status 200).

#5. Troubleshooting

  • If you see CORS errors, double-check ALLOWED_ORIGINS and restart the API.
  • If the app cannot connect, verify your phone and server are on the same WiFi/LAN.
  • Use docker logs payday-api --tail 50 to check backend errors.

For further issues, provide error details for targeted fixes.

~ End of Document ~