DEV Community

Cover image for I'm 12. I ran a global Code Jam on a $150 phone. Here’s the Supabase architecture that held it together. 🐯
Harun - solo dev
Harun - solo dev

Posted on

I'm 12. I ran a global Code Jam on a $150 phone. Here’s the Supabase architecture that held it together. 🐯

Two weeks ago, I had zero submissions for my coding festival.
Yesterday, I crowned the first Champion of the KODA Code Jam, upgraded their database status, and launched a second Jam (Scribe Jam), all while managing a community of 3,000+ developers.

I am 12 years old. I do not have a laptop. I build full-stack AI applications entirely on a POCO C55 Android phone.

And none of this would be possible without @kiwicopple ** (Paul Copplestone) and the team at **Supabase.

Here is exactly how I use Supabase to run a real, global developer ecosystem from my phone.


1️⃣ Authentication at Global Scale

My community isn't local. I have users like vpxudon (a senior engineer from China), puneetkumar2010 (a 15-year-old builder from India who just won the Jam), and nyaomaru (User #001 from Japan).

Supabase Auth handles this seamlessly. I don't have to worry about session management or password hashing. I just call supabase.auth.signInWithPassword(), and it works perfectly on mobile browsers.


2️⃣ Row Level Security (RLS) is My Best Friend

As a solo dev, security is my biggest anxiety. I am handling user profiles, submission data, and error logs.

I rely heavily on PostgreSQL Row Level Security (RLS).
For example, in my scribe_submissions table, I have an is_champion boolean flag. I wrote policies ensuring that while anyone can SELECT public submissions, only authenticated users with specific admin claims can UPDATE the champion status.

Supabase made RLS accessible enough for a 12-year-old to implement correctly without needing a dedicated backend security team.


3️⃣ The "Silent Failure" Lesson (Telemetry)

Recently, a senior DevOps engineer (Nnamdi) reviewed my architecture and pointed out a flaw: my error logs were only catching failures, not successes. If my primary AI model failed and my fallback succeeded, I had no idea which model actually served the request.

The Fix: I added a model_served text column to my Supabase error_logs table. Now, every request logs the attempted model and the actual served model.

-- Example of the telemetry I now track in Supabase
UPDATE error_logs 
SET resolved = true, resolved_at = now() 
WHERE error_type = 'http_404' AND resolved = false;
Enter fullscreen mode Exit fullscreen mode

This simple Supabase database update turned my "silent failures" into visible, actionable data.


4️⃣ Why I'm Not Switching

I have fought with hosting providers. I have dealt with broken build pipelines. But Supabase has been the one constant, reliable foundation.

The dashboard works flawlessly on my mobile browser. The PostgreSQL database is robust. The documentation is clear enough for a beginner to grasp, but powerful enough for senior engineers to respect.


🐯 To the Supabase Team

@paulc and team: Thank you for building a tool that democratizes backend development. You didn't just build a database; you built a ladder. And kids like me are using it to climb higher than we ever thought possible.

We are cooking. And Supabase is the stove. 🔥


Questions? Drop them in the comments. I read every single one.

Top comments (1)

Collapse
 
koda2026 profile image
Harun - solo dev

First comment goes to the community! 🐯👇

If you are building on a budget, building entirely on a phone, or just starting your dev journey: what has been your biggest "aha!" moment or favorite feature in Supabase so far?

Also, if you want to put your skills to the test, the Scribe Jam is officially open (link in my profile/articles). Build a niche documentation tool and win eternal glory (and some epic database upgrades).

Let's keep cooking! Drop your thoughts below. 🔥