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

> Source: <https://dev.to/koda2026/im-12-i-ran-a-global-code-jam-on-a-150-phone-heres-the-supabase-architecture-that-held-it-4jkk>
> Published: 2026-09-15 14:43:29+00:00

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](https://dev.to/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.

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.

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.

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;
```

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

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.

@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.