How I Built a Free Python Practice Platform With Zero Server Costs Using Groq and Supabase

I wanted to build a Python coding challenge platform that generates a completely unique problem every single time. No question bank. No repetition. Genuinely infinite practice.

The challenge was cost. AI API calls cost money. If thousands of students use a tool daily, the API bill scales with them. Most free tools either cap usage or die when they hit their billing limit.

Here is how I built PyCodeIt with a Bring Your Own Key (BYOK) architecture that keeps server costs at zero while giving users a completely frictionless experience.

The Architecture

┌─────────────────────────────────┐
│         User's Browser          │
│                                 │
│  Next.js App (Vercel)          │
│  ├── Challenge UI               │
│  ├── Auth (Supabase JS)         │
│  └── API Key (localStorage)     │
└──────────┬───────────────┬──────┘
           │               │
           ▼               ▼
      Supabase       OpenRouter API
     (Auth, DB,     (Direct from browser
  Edge Functions)    using user's key)

The key insight: if the AI call goes from the user's browser to OpenRouter using the user's own API key, there is no server cost to me. By relying on OpenRouter, users gain access to a pool of 8 different models, and the system can handle instant fallback logic automatically if a specific provider encounters any latency or rate limits.

The Frictionless UX: No Forced Signup

The BYOK model usually creates friction because it forces visitors through a lengthy checklist before they can even see the product.

To combat this, PyCodeIt allows users to start practicing immediately with or without signing up. A user can simply land on the site, paste their OpenRouter API key directly into the application, and generate a problem instantly.

For users who want to track their progress, authentication and score tracking are available via Supabase, which is free up to 50,000 monthly active users:

• Authentication with email and Google OAuth
• PostgreSQL database for scores and streaks
• Row Level Security so users only access their own data

The schema for the scoring system looks like this:

CREATE TABLE user_stats (
  user_id UUID REFERENCES auth.users(id) PRIMARY KEY,
  xp INTEGER DEFAULT 0,
  streak INTEGER DEFAULT 0,
  best_streak INTEGER DEFAULT 0,
  total_solved INTEGER DEFAULT 0,
  easy_solved INTEGER DEFAULT 0,
  medium_solved INTEGER DEFAULT 0,
  hard_solved INTEGER DEFAULT 0,
  last_active DATE DEFAULT CURRENT_DATE
);

ALTER TABLE user_stats ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users manage own stats"
ON user_stats
USING (auth.uid() = user_id);

The Problem Generation Prompt

The prompt structure that consistently returns clean, structured JSON across the configured fallback models:

const prompt = `Generate a unique Python ${difficulty} dry-run problem about ${concept}.
The user must predict the exact terminal output.
Make it genuinely tricky but fair for ${difficulty} level.

Return ONLY valid JSON with exactly these keys:
{
  "title": "string",
  "concept": "string",
  "code_snippet": "string (valid Python with print statements)",
  "correct_output": "string (exact terminal output)",
  "hint_1": "string",
  "hint_2": "string",
  "explanation": "string (step by step trace)"
}
Do not include any text outside the JSON object.`;

Enforcing response_format: { type: "json_object" } in the API call eliminates parsing errors and ensures structural consistency.

The Security Honest Assessment

The main trade-off with a pure browser-based BYOK setup is that API keys are visible in network requests. A technically sophisticated user can open browser developer tools, inspect the network tab, and see their API key being sent out.

This is a risk to the user, not to the platform. The key is theirs. However, I handle this by being completely transparent in the UI:

• Transparency: A note near the API key input explains exactly where the key is stored (localStorage) and how it is used (sent directly to the AI router from the browser, never to my servers).
• Minimal permission guidance: The UI links to instructions on creating restricted OpenRouter keys or setting strict budget limits.
• Easy rotation: A visible "Clear API key" button makes it trivial to wipe the key from localStorage instantly.

What I would do differently if building again: I would pass all requests through a Supabase Edge Function proxy. The user's key would still be used for the actual AI request, but it would flow through the serverless function rather than directly from the client network tab. This completely hides the key from frontend inspection while still utilizing the user's personal quota.

Conclusion

By keeping the platform decoupled from an expensive central API budget and removing mandatory account creation, the product remains highly accessible and cost-free to run. The only thing that would push me to paid tiers is outgrowing Supabase's 50k monthly active users limit, which is a good problem to have.

The platform is live at pycodeit.com if you want to see this architecture running in production. Try it out at pycodeit.com and feel free to drop a comment if you want to discuss any aspect of the implementation.

Written by the developer behind PyCodeIt, a free AI-powered Python dry-run practice platform for technical interview preparation.