Teaching Frontend Devs to Build Backends: The Supabase Approach

Note: Some names have been generalized. The lessons are real.

The problem with “Full Stack” juniors

I had a problem. We needed to build Wookie, a complex real-time booking platform. But I didn’t have a backend team.

I had the Mobile Team. Bright, talented juniors who could build beautiful UI in their sleep, but who thought “Postgres” was a type of dinosaur.

The traditional approach would be to:

Hire a Senior Backend Lead (expensive, takes months)
Do it myself (I’d be the bottleneck)
Teach them Node.js/Express/DevOps (too much friction)

We chose option 4: Remove the friction.

Why Supabase was our “Training Wheels”

I chose Supabase not just because it’s fast, but because it exposes the right things.

If I taught them Node.js, we’d spend 3 weeks debugging Express middleware and Nginx configs. I didn’t care about that. I wanted them to understand Data Modeling and Security.

Supabase strips away the server maintenance so you’re staring raw SQL in the face. It forces you to learn databases, not frameworks.

What we taught:

SQL basics (SELECT, INSERT, UPDATE, DELETE)
Database design—relationships, normalization, indexes
PostgreSQL-specific features
Supabase concepts—Row Level Security (RLS), Functions, Triggers, Edge Functions

How we taught it:

Gave them time for quick, short self-paced introductory programs (Q4 2022 - Q1 2023)
Had them group up and compare their work with each other—learning from peers
Reviewed what they built and gave feedback (with help from part-time senior developers)
Just enough to build Wookie—deep learning came from building

The hardest part: not giving them the answer

The hardest part of mentorship isn’t knowing the answer. It’s resisting the urge to give it directly

During the build, a junior hit a performance issue with a slow query. I knew what the fix was—an unindexed column. My instinct wanted to just tell them the solution

But that fixes the bug, not the engineer

Instead, I asked: “What does EXPLAIN ANALYZE say?”

They came back later having figured out it was doing a sequential scan. I asked how to stop it from reading every row. They figured out: indexes.

The problem took longer to solve this way. But they learned how to debug performance issues, not just this fix. The next week, I saw them proactively adding indexes to other tables.

That’s the ROI of asking questions instead of giving answers.

Note: Details of this exchange have been simplified and dramatized for narrative clarity. The core lesson is asking questions instead of giving answers, which reflects the actual mentoring approach used throughout the project.

The “No GOD Tables” Rule

To keep the code production ready while they learned, I couldn’t just let them run wild. I set up Architecture Decision Records (ADRs) with non-negotiable rules.

Such as No GOD Tables., No GOD Functions., No GOD Triggers.

Inexperienced developers love creating a users table with 85 columns:

username
favorite_color
last_login_ip
is_hungry

I required them to normalize. “If you want to store user preferences, make a preferences table. If you want to track logs, make a logs table.”

We used Row Level Security (RLS) as our exam. we told them: “I don’t care what your frontend code says. If I can run a CURL command and delete the CEO’s seat booking, you fail.”

It worried them. And because they were worried, they learned security first, not last.

Example RLS policy:

-- Only users can see their own bookings
CREATE POLICY "Users see own bookings"
ON bookings FOR SELECT
USING (auth.uid() = user_id);

-- Only admins can modify any booking
CREATE POLICY "Admins modify all bookings"
ON bookings FOR ALL
USING (is_admin(auth.uid()));

The RLS learning curve was steeper than I expected. We wrote the same buggy policy several times before We created example templates

Another story: The duplicate logic problem

A junior came to me: “I’m writing the same seat availability check in three different functions.”

My instinct was of course to tell them to “Extract it into a shared function.”

Instead, I asked:

“Where are you using this logic?”
“What happens if the logic needs to change?”
“How many places would you need to update?”
“What pattern could solve this?”

They realized “Oh, I should create a function.” and then they did

Example of the solution:

CREATE FUNCTION can_user_book_seat(seat_id UUID)
RETURNS BOOLEAN AS $$
BEGIN
  -- Check if seat exists
  -- Check if seat is available
  -- Check if user has quota
  RETURN true;
END;
$$ LANGUAGE plpgsql;

Now anywhere we need that logic: SELECT can_user_book_seat('seat-uuid');

DRY (Don’t Repeat Yourself) principle: Bugs fixed once, not in 10 places.

The only problem with this was that Supabase functions are bad in terms of documentation and version history which needed custom documentation and management

Scaling mentorship

If I’m the only one who can mentor, we don’t scale. The senior mobile developers handled code reviews and guided juniors through SQL and database concepts.

The other part time mentors helped when they can, we split our responsibilities since we also had other responsibilities.

The key was consistency, always ask questions, don’t give answers immediately. When a junior asks a question, the instinct is to give the solution. But guiding them to the answer themselves by asking smaller questions, letting them type while you correct, that’s what makes the learning stick.

Did they actually learn?

The proof isn’t in the app (though Wookie hit 100% adoption). The proof is in their careers.

Those juniors aren’t just “frontend devs” anymore.

Some are multi-stack developers, switching between native mobile and backend
Some became Cloud Engineers
Some act as Mentors to the next batch of trainees

They stopped treating the database as a “black box” they were afraid to touch

Specific outcomes:

The team shipped real-time features, proper security (RLS), and clean architecture (DRY, no GOD tables)
Knowledge transferred—team members used these skills on client projects
Juniors who started with zero SQL experience were writing production database code with proper security

What worked, what didn’t

What Worked ✓	Why
Supabase as Learning Platform	Abstracts complexity without hiding it. Juniors wrote SQL directly, saw RLS in action, used familiar SDKs, deployed without DevOps complexity
Just-in-Time Learning	Taught while building, not in a vacuum. Context made learning stick
Hard Requirements Through Reviews	"Where's the RLS policy?" became automatic. No RLS? No merge
Questions Instead of Answers	Juniors learned deeper and retained longer because they discovered solutions themselves

Supabase as Learning Platform

Why

Abstracts complexity without hiding it. Juniors wrote SQL directly, saw RLS in action, used familiar SDKs, deployed without DevOps complexity

Just-in-Time Learning

Why

Taught while building, not in a vacuum. Context made learning stick

Hard Requirements Through Reviews

Why

"Where's the RLS policy?" became automatic. No RLS? No merge

Questions Instead of Answers

Why

Juniors learned deeper and retained longer because they discovered solutions themselves

What Didn't Work ✗	The Lesson
Assuming Same Learning Pace	Some picked up SQL in a week, others needed more time. Could've made some specialists and shared workloads, but chose breadth over depth.
Not Documenting Pitfalls Early	Hit the same bugs multiple times before creating "Common Mistakes" doc. Should've done it earlier
Underestimating Database Learning Curve	Inconsistent naming standards. Should've imposed stricter standards upfront instead of pure experimentation.
Underestimating RLS Learning Curve	Should've created more example policies upfront

Assuming Same Learning Pace

The Lesson

Some picked up SQL in a week, others needed more time. Could've made some specialists and shared workloads, but chose breadth over depth.

Not Documenting Pitfalls Early

The Lesson

Hit the same bugs multiple times before creating "Common Mistakes" doc. Should've done it earlier

Underestimating Database Learning Curve

The Lesson

Inconsistent naming standards. Should've imposed stricter standards upfront instead of pure experimentation.

Underestimating RLS Learning Curve

The Lesson

Should've created more example policies upfront

Main takeaways

1. Work with what you have. No backend devs? Teach the frontend devs. Constraints force creativity.

2. Choose tools that remove noise. Supabase let juniors see SQL, RLS, and real-time features without drowning in DevOps.

3. Ask questions, not give answers. Let them struggle to find the solution. They’ll learn deeper and retain longer.

4. Enforce discipline through reviews. “No RLS? No merge.” Hard requirements keep quality high.

5. Scale through teaching teachers. Mentor the mentors. Your impact multiplies.

6. Just-in-time learning beats theory. Teach while building. Context makes it stick.

If you’re a lead staring at a team of “Frontend Only” devs, don’t write them off.

Give them tools that remove the noise (like Supabase or Firebase or AppWrite). Give them hard constraints (like RLS). And most importantly, ask questions instead of giving answers immediately.

Your limitations can become your training ground.

Related:

Wookie: The Complete Story - Full case study with outcomes
Why We Rebuilt from KMP to Flutter - The strategic rebuild decision