CodecityApp has 1,334 challenges across 10 languages. I built it alone. No co-founder, no engineering team. Here's the real stack and the mistakes I'd avoid.
The stack
Frontend lives in Lovable — React + Vite + Tailwind under the hood. Backend runs on two Supabase projects (I'll explain why that's a trap). Code evaluation goes through Judge0, wrapped in a Supabase edge function with IP rate limiting and a 5-second execution ceiling. The AI mentor is Claude running as an edge function. Email and outreach run through another Claude agent — fully autonomous, fires on a schedule, handles replies.
I wrote maybe 20% of the code by hand. The rest came out of Lovable prompts and direct API calls.
The two-Supabase trap
Lovable spins up its own Supabase project automatically. I also had a production Supabase project where I'd built all the edge functions, crons, and email infrastructure before connecting Lovable.
So now I had two projects. One with real backend logic. One that Lovable owned.
For months I'd debug something in production and the dashboard would show different numbers. Edge functions deployed to the wrong project. API keys wired to the wrong database. Cron jobs firing in one project with no effect on the data in the other.
If you're starting fresh: pick one Supabase project, connect Lovable to it from day one. Don't let Lovable spin up its own.
The bugs that will wreck you aren't in the code
Two things that cost me weeks:
One. The challenge progression system was hardcoded open for months. Every world was accessible regardless of what users had actually completed. I was testing my own account (which had everything done) and never caught it. Real users had no structured path. Retention felt off but I couldn't diagnose why until I watched a real session.
Two. My B2B outreach pipeline showed five clicks from leads including Codecademy and MIT OpenCourseWare. I thought we had genuine interest. Every single click was Microsoft Defender and Proofpoint firing automated link scanners, 21–33 seconds post-send, with no preceding open. Zero human engagement.
Both came from building fast and not verifying what was actually shipped vs. what I assumed was shipped. Lovable will tell you "COMPLETE" while the live site still shows the broken state — CDN lag, or the fix went to the wrong component. Always verify on the live domain.
The AI agent part people don't talk about
ARIA is a Claude-powered sales agent that reads inbound replies, scores them, picks a follow-up tactic from a library, writes the email, and sends it — on its own schedule, without me in the loop.
Building that was the most interesting part of this project. Not because it's technically complex, but because writing the system prompt for an autonomous agent that has to handle objections, read context, and sound like a real person is genuinely hard. Most autonomous email agents sound like robots. Getting ARIA to sound like a founder writing at 7am took more iterations than any other single feature.
The short version: give it a persona with specific constraints, not generic instructions. "Sound professional" produces garbage. "Never open with the company name as the first word. Lead with something specific about the recipient." produces something usable.
What I'd do differently
Start with a real user in session 1, not session 100. I spent too long building and not enough time watching someone use it cold. The city metaphor — where writing code constructs actual buildings — landed immediately for every person who saw it. I didn't know that for a long time because I was too deep in the build to test it cleanly.
The vibe coding workflow is real and it's fast. The risk isn't that the AI builds the wrong thing. The risk is that you don't catch what it built wrong until much later.
If you're building in a similar stack or have hit the two-Supabase problem, happy to get into specifics in the comments.
→ codecityapp.com — guest challenges work with no account if you want to see the city mechanic.
Top comments (0)