What I Learned Building Roberts Intelligence with Figma Make

🧪 Experiment:

I wanted to push Figma Make beyond simple UI generation and use it to build a fully data-driven SaaS with:

• user profiles

• clients

• projects

• work logs

• feedback

• subscription logic

…and connect everything to a real relational schema in Supabase (Postgres).

⚠️ What actually happened:

I discovered something important:

➡️ Figma Make cannot create or use real Supabase tables.

It only works with a predefined Key-Value Store (kv_store) — a single table with JSON blobs.

No matter what schema you prompt it to build (clients, projects, work_logs, etc.), Figma Make will respond with something like:

“I cannot create new tables or run migrations in Supabase.
I can only store everything in the existing KV store.”

This means:

🔸 No relational data
🔸 No real SQL queries
🔸 No migrations
🔸 No table-level security (RLS)
🔸 No scalable multi-user model
🔸 No true backend logic

Which is fine for quick prototypes…
…but not for real SaaS architecture.

🧠 My takeaway:

Figma Make is amazing for UI prototyping and for generating “feel-like-real” flows fast.
But it’s not yet a backend-ready tool and cannot replace Lovable or a real Next.js/Supabase stack for:

• feature validation

• multi-user SaaS

• subscription logic

• real database design

• production systems

For now:

🔹 Lovable → better for full-stack prototypes
🔹 Figma Make → great for UI/UX and quick concept demos
🔹 Real code (Next.js + Supabase) → required for product validation, scaling, and real usage

💡 If you're testing an idea:

Figma Make gets you 40% there (UI + flows).
Lovable gets you maybe 70%.
But launching a real SaaS still needs real code — especially when your product depends on relational data and reporting.

🎯 Next step for me:

Finish prototyping with Figma Make → rebuild Roberts Intelligence’s backend properly in Next.js + Supabase using real tables and RLS.