DEV Community: Francesco Costantino

How I built a viral gaming SaaS with my 14yo son (and survived a massive traffic spike on AWS without going bankrupt)

Francesco Costantino — Wed, 08 Apr 2026 07:21:15 +0000

It started on a random Saturday afternoon with a simple question from my 14-year-old son: "Dad, how much is my Brawl Stars account actually worth?"

We searched online. Nothing but shady websites asking for passwords or outdated forums. So, as a Dev with 20 years of experience, I said: "Let's build it ourselves."

48 hours later, BrawlValue.com was born.

What started as a simple API calculator accidentally turned into a massive, hyper-local gamified platform. The Gen-Z kids didn't just want to know their account value; they wanted to flex it. We introduced School and City Leaderboards.

The result? The "Dark Social" (WhatsApp school groups) exploded. In just a few days, we mapped over 1,500 schools, acquired 5,000+ verified users via Discord OAuth2, and handled massive traffic spikes driven by top gaming influencers.

Here is how I architected the system to survive the hype without paying thousands of dollars to Jeff Bezos.

1. The Nginx "Russian Roulette" Hack (Bypassing Rate Limits)

The official game API has strict rate limits per IP. When a famous YouTuber dropped a video about our site, we expected thousands of concurrent requests to fetch the same Player Tags. A standard setup would have resulted in 429 Too Many Requests and a crashed site.

The Solution: I generated 3 different API keys for my single AWS EC2 IP. Then, I used the native Nginx split_clients module to balance the load evenly across the keys based on the $request_id.

split_clients "${request_id}" $brawl_token {
    33.3%   "TOKEN_1";
    33.3%   "TOKEN_2";
    *       "TOKEN_3";
}

Combined with proxy_cache_lock on; (to prevent the Thundering Herd problem), this single Nginx trick absorbed the entire traffic spike. Zero Node.js overhead.

2. Offloading Compute to PostgreSQL (Supabase)

I initially ran a c6i.xlarge EC2 instance, but calculating dynamic ranks for 5,000 users across 1,500 schools in Node.js was a memory-leak nightmare waiting to happen.

I shifted the entire load to Supabase (PostgreSQL). Instead of sorting arrays in JS, I wrote a materialized View using Window Functions:

RANK() OVER (PARTITION BY season_id, school_id ORDER BY flex_score DESC) as school_rank

Node.js simply fetches a pre-calculated JSON. CPU usage on my AWS instance dropped to 0.08%. I literally downgraded the server to a t3.small during the peak and saved my wallet.

3. AI-Powered Zero-Click Moderation (Qwen3-VL)

To enter the Leaderboard, users must prove they own the account. Manual verification for 5,000 kids? Impossible.

I built a custom Discord Bot using discord.js. Users simply drop a screenshot of their game profile in a specific channel. The bot instantly opens a private thread, sends the image to Alibaba Cloud's Qwen3-VL (an ultra-fast Multimodal LLM), extracts the Player Tag via OCR, verifies it against the DB, and auto-assigns the "Verified" role. 100% automated KYC for teenagers.

4. The "Ego-Trap" Monetization (Webhook Magic)

How to monetize kids who don't have credit cards? You sell social status.
We created a "VIP Brawler" role. Users pay €3 via Ko-Fi.
Ko-Fi triggers a Webhook ➔ My Node.js server parses the payload ➔ Updates Supabase (is_vip: true) ➔ The Next.js frontend instantly turns their generated "Share Card" into a glowing Gold/Neon design.
Zero manual work. Pure passive income driven by gaming vanity.

🚀 Today, we are launching on Product Hunt!

We transitioned from a weekend toy to an enterprise-grade Data-Scouting architecture. We are now officially launching Season 1 and trying to make some noise on Product Hunt.

If you love bootstrapped projects, dirty but highly effective Nginx hacks, and indie-hacking survival stories, I would love your honest feedback and support on our launch page today! 👇

🔗 https://www.producthunt.com/products/brawl-value

Let me know in the comments if you have any questions about the stack, Supabase RLS, or how to handle Gen-Z traffic spikes!

How I built a Serverless, P2P Parental Control app using WebRTC and Kotlin

Francesco Costantino — Sat, 06 Dec 2025 22:31:01 +0000

As a parent and an Android developer, I faced a dilemma. I wanted to monitor my child's activity on TikTok and YouTube to ensure their safety, but I hated the privacy implications of existing parental control apps.

Almost every commercial solution works the same way:

Collect child's data (location, history, app usage).
Upload everything to a centralized Cloud Database.
Display it on the parent's phone.

I didn't want my child's location history sitting on a third-party server. So, I decided to over-engineer a solution for myself. I spent the last 6 months building SafeStream, a completely serverless, Peer-to-Peer monitoring system.

Here is how I built it using Kotlin, Jetpack Compose, and WebRTC.

The Architecture: "No Backend" approach
The core idea is simple: The Parent device is the server. Data should flow directly from Device A (Child) to Device B (Parent) without persisting anywhere in between.

To achieve this, I used WebRTC (Web Real-Time Communication) not for video calls, but for its DataChannels.

Guardian App (Child): Runs a background service that collects data locally. It acts as a WebRTC peer.

Parent App: Acts as the viewer peer. It receives JSON payloads directly and stores them in a local Room (SQLite) database.

Signaling: I use Firebase Realtime Database strictly for the handshake (SDP Offer/Answer exchange). No user data touches Firebase.

The Tech Stack
Language: 100% Kotlin.

UI: Jetpack Compose (Material3) for a modern "Reel-like" feed.

P2P: Google's WebRTC library wrapped in a custom WebRTCConnectionManager.

Traversal: STUN/TURN servers to bypass NATs and firewalls (essential for 4G/5G connections).

Encryption: AES-256-GCM on top of WebRTC's DTLS (Paranoia level: High).

Key Technical Challenges
1. Extracting Video Metadata (The ethical hack)
TikTok and YouTube don't offer APIs for "watch history". I implemented an Accessibility Service (GuardianAccessibilityService.kt) that scans the UI hierarchy.

It detects when the user is in a video app (com.zhiliaoapp.musically or com.google.android.youtube).

It scrapes the contentDescription or text of the visible views to extract the video title and channel.

Optimization: To avoid battery drain, this logic is heavily debounced and only runs when the screen content changes.

2. The WebRTC Handshake in Background
Keeping a WebRTC connection alive in the background on modern Android is... painful. Android's Doze Mode and App Standby Buckets are aggressive.

Solution: I implemented a foreground service with a persistent notification.

Turn-on-demand: The connection isn't always open. The Parent sends a high-priority FCM (Firebase Cloud Message) to "wake up" the Child device, which then initiates the WebRTC signaling process.

3. Transferring Images over P2P
Sending high-res screenshots over a DataChannel requires chunking. WebRTC has a limit on message size (approx 16KB to be safe). I wrote a chunking algorithm that splits the Bitmap (compressed as WebP) into small binary packets, sends them sequentially, and reassembles them on the Parent side.

The Business Model (Indie Dev Reality)
I'm releasing this app for free. However, running TURN servers (bandwidth relay) costs money. To make it sustainable without subscriptions or selling data, I implemented a Credit System:

Text logs and real-time location are free (low bandwidth).

Downloading high-res screenshots costs "Credits".

Users get free daily credits or can watch a Rewarded Ad (AdMob) to refill them. This pays for the TURN bandwidth.

What's Next?
I'm launching the Open Beta next week. I'm looking for feedback on the P2P stability across different network carriers (CGNAT is my enemy).

If you are curious about the P2P implementation or want to test it out, check it out here: safestreamguardian Architecture - beta subscription

Happy coding! 🚀