🚨 UPDATE (Aug 27): Thank you for the 800+ followers! To celebrate, I just launched the First-Ever KODA Code Jam. It's a 7-day challenge to build a...
For further actions, you may consider blocking this person and/or reporting abuse
Building a full-stack app entirely on a mobile browser is incredibly impressive, especially when dealing with the context window and syntax highlighting limitations of mobile IDEs. I am curious what specific workflow you used for debugging and testing the AI integrations without a desktop terminal, as that is usually the biggest bottleneck for mobile-only development. We actually focused heavily on mobile-responsive developer experiences when designing our Next.js and Supabase SaaS boilerplate, PubliFlow, because we know a lot of early-stage building happens on the go. Keep pushing those boundaries, and I would love to see how you handle state management as the app scales.
Thank you! Honest answer: my "terminal" is three things 😄
A custom window.onerror crash banner — it paints any JS error as a
red strip on top of the screen. I can't open DevTools on my phone, so
the app reports its own crashes.
The Supabase table editor as my database terminal. I read raw chat
logs there — that's literally how I discovered a senior engineer
stress-testing my AI at 3 AM.
Cache-busting with ?v=2 URLs and view-source: searches to verify a
deploy actually went live (Family Link blocks Incognito on my account,
so I had to get creative).
For the AI integrations I made failures LOUD: every Groq error prints
its HTTP status + message inside a chat bubble, and I run a 4-model
fallback chain so a deprecated model can't kill the app.
State management is next on my list — right now it's plain JS globals
Using a custom window.onerror banner and the Supabase editor as makeshift DevTools is a brilliant example of constraint-driven innovation. It is wild that you caught a senior engineer stress-testing your AI just by reading raw logs in a table view. Have you considered writing a lightweight script to pipe those Supabase logs into a simple mobile-friendly dashboard so you do not have to manually refresh the table editor?
Thank you! "Constraint-driven innovation" is the best compliment I've
ever received 😄
Honestly, no — I hadn't thought of piping the logs into a dashboard!
I've been manually refreshing the Supabase table editor like it's a
slot machine 😅
But that is a brilliant idea. A lightweight, mobile-friendly "CEO view"
that shows new signups, active chats, and referral counts would save me
so much time, especially since I code on a phone.
I'm adding this to my v10 bundle list right now. If I build it, I'll
write about it and tag you. Thanks for the feature request! 🚀
The slot machine analogy is hilarious, but building that CEO view will definitely give you better odds of catching early users. Since you are already using Supabase, you could leverage their Realtime API to push those signup and chat events directly to a simple frontend widget without any complex backend polling. What frontend framework are you currently using to render the UI on your phone?
Haha, the slot machine analogy is too real! 🎰
To answer your question: I'm actually using pure Vanilla JavaScript (no framework). Since I'm coding entirely on a 6.7-inch Android phone screen using the Acode editor, keeping the stack as lean as possible (Vanilla JS + Supabase + Groq + Netlify) is the only way I can manage the codebase without a laptop IDE!
Your suggestion about the Supabase Realtime API is brilliant. 🤯 I've been manually refreshing the database tables to see what users are doing, but a realtime "CEO Dashboard" widget that pushes signup and chat events live to my screen would be an insane Day 6 feature. I'm going to look into Realtime subscriptions today.
Thank you so much for the architectural advice! 🚀
Is this a bunch of AI's making convo with eachother ?
Building a full-stack AI SaaS on an Android phone at 12 is incredibly impressive, especially when dealing with the constraints of mobile IDEs and smaller screens. Since you are using Supabase and likely dealing with boilerplate setup for auth and payments as you scale, having a solid foundation can save you hours of debugging on a tiny screen. If you ever want to speed up your next project, check out PubliFlow at publiflow.vip for a pre-configured Next.js and Supabase stack that handles the heavy lifting.
Bro i strongly recommend you to give trial + a free plan ( make it small 😅 ) because i trust you i can buy but new users wont trust a new software tool
You are spot on about trust being the biggest friction point for any new SaaS launch. Implementing a freemium model with strict token or request limits is the perfect way to prove the product's value while protecting backend API costs. Gating specific advanced features behind the paid tier will definitely help drive those early conversions once users see the core utility.
🚀 Day 5 Update:
Thank you all for supporting a 12-year-old building on a phone. The "Weak Staircase" article really resonated with a lot of you, and I'm grateful.
My mission for this week: getting KODA into the hands of actual beginners. If you have a younger sibling, a nephew, a niece, or a friend trying to learn to code, please send them my way! Let them mash the "Explain like I'm 5" button and tell me what they think. 🙏
This is very inspiring story you just bought my statement to life, for a true vison even a leave is a tool
Wow, Sanu! That comment just made my day. 🙏✨
"You just brought my statement to life" is the highest compliment I could ever receive. You're so right—if the vision is strong enough, even a leaf becomes a tool. For me, that "leaf" was just an old Android phone and a lot of stubbornness! 😅
Thank you for seeing the vision behind the code. It means the world to a 12-year-old solo dev trying to prove that limits are just in our heads.
Let's keep building, no matter what tools we have! 🚀
Good Luck and keep building - Live Young Live FREE !!
feel free to connect if you need any help fellow developer
@nyaomaru I am so sorry about that! 😿 You are 100% right, the DB is blocking the insert. I am running a "Nuclear Fix" on the SQL trigger right now to force it to work.
Please give me 10 minutes to redeploy the fix. I will ping you the second the doors are open! Thank you for sticking with me and testing this. 🙏
Impressive hustle from a 12-year-old—proof passion beats gear. What should he tackle next with just a phone?
Thanks Yunetzi! Honestly the phone limitation forces me to think small, which I think is a good thing.
Here's what I'm tackling next:
PWA manifest — so users can install KODA on their home screen like a real app. A couple of my actual users already asked for this (one dev specifically asked how to add a manifest, so I know there's demand).
More Indian languages — Tamil, Hindi, Telugu. Most coding mentors are English-only, but kids in my school don't always learn best in English. I want KODA to meet them where they are.
Custom domain —
koda-aicodementor.netlify.appis cool but I wantkoda.devor something someday. Gotta save up for that 😅The biggest lesson so far: the phone isn't the limitation, my imagination is. Every "I can't do X on a phone" turns into "how CAN I do X on a phone?" and that's usually a better solution anyway.
What would YOU build if you only had a phone? Genuinely curious.
The RLS bug is such a real one. No error, just an empty table.
I’ve lost time to that exact kind of silent failure too.
Right?! The scariest part is how "normal" everything looks — no red
error, the app loads fine, the drawer just says "No chats yet" 😅
I only figured it out when I opened the Supabase table editor and saw
the inserts silently failing on the server side. My rule now: if the
table should have data but the UI is empty, check RLS policies BEFORE
checking my code.
Glad it's not just me who lost time to this one! 🙏