Difficulty: Intermediate · Last updated: December 5, 2026 · By Mantlr Editorial
A practical guide to adding a backend to Figma Make — what works, what doesn't, and how to ship working apps with real data.
Key takeaways
Six things to know about Figma Make backends before you add one:
1. Make integrates with Supabase by default — Postgres database, auth, storage, Edge Functions
2. Make uses Supabase as a key-value store rather than full SQL schemas in most cases
3. Add a backend with a simple prompt: "Add user authentication" or "Add a database to store submissions"
4. Free Supabase tier is enough for prototype workloads; production scale needs paid Supabase
5. The backend connection is per-Make-file — each Make file connects to its own Supabase project
6. Edge Functions handle serverless backend logic; Vector embeddings enable AI features
On this page
- When does a Figma Make app need a backend?
- What does Figma Make's backend integration include?
- Step 1: Plan your backend needs
- Step 2: Add a backend via prompt
- Step 3: Connect your Supabase account
- Step 4: Build auth flows
- Step 5: Add database storage
- Step 6: Add file uploads
- Step 7: Use Edge Functions for custom logic
- Step 8: Use Vector embeddings for AI features
- Common backend setup mistakes
- What you can't do with Figma Make's backend
- Frequently asked questions
- Related articles
Static prototypes are useful. Working prototypes with real data are transformative. The difference is a backend — and adding one to a Figma Make app is faster than most designers expect.
Figma Make integrates with Supabase to provide backend services: a Postgres database, authentication flows, file storage, secret management, and serverless Edge Functions. Add a backend with a simple prompt. Make handles the configuration, sets up the database connection, and generates the working code. From idea to working app with real user accounts: under an hour for most prototypes.
This guide walks through what's possible, when to add a backend, and how to use Supabase effectively from inside Figma Make. It covers auth, databases, file storage, Edge Functions, and the AI features that vector embeddings unlock. Written for designers and founders building prototypes that need real interactions, not just visual mockups.
If you're new to Figma Make, read What Is Figma Make? first. For the broader Make workflow, see How to Use Figma Make.
Quick wins
1. Don't add a backend until you need one. Static Make apps are faster to build and easier to iterate. Backends add complexity.
2. When you do need one, just prompt it: "Add user authentication and a database to store posts." Make handles the rest.
3. Use the Supabase free tier for prototypes. Move to paid only when you're testing with real users at scale.
When does a Figma Make app need a backend?
Not every prototype needs a backend. Adding one prematurely slows iteration and complicates testing. Three signs you actually need one:
You need user accounts. Anything with login, signup, password recovery, or per-user data. Without a backend, every user sees the same state — fine for marketing pages, not for apps where users have their own data.
You need persistent data. Anything where data should survive page refreshes or be visible to multiple users. Habit trackers that remember progress, marketplaces where listings persist, comment systems where messages remain after submission.
You need file uploads. Anything where users upload images, documents, or media. Profile photos, document attachments, image-based posts.
You need to call external APIs securely. Anything that requires API keys or secrets that shouldn't be exposed in client-side code. OpenAI calls, Stripe webhooks, third-party integrations.
If your prototype is none of these, skip the backend. Static Make apps with mock data are faster to build, easier to iterate, and sufficient for many demo and validation scenarios.
What does Figma Make's backend integration include?
The Supabase integration provides five capabilities:
1. Postgres database. Real PostgreSQL database for storing user data, app state, and content. Make uses it as a key-value store in most cases — flexible but less structured than full SQL schemas.
2. Authentication. Email/password auth, OAuth (Google, GitHub, others), magic links, password recovery. Make sets up the auth flows when you prompt for them.
3. File storage. Secure file uploads with access controls. Useful for user-uploaded images, documents, or media.
4. Secret storage. Secure storage for API keys and secrets. Make uses these in Edge Functions to call external APIs without exposing keys client-side.
5. Edge Functions. Serverless functions that run close to users. Use them for custom backend logic, API integrations, scheduled tasks, and data transformations.
6. Vector embeddings. Storage and search for high-dimensional data (text, images). Enables AI-powered features like semantic search, recommendations, and personalization.
Together, these give you most of what you'd need for a real production app — though with simplifications that make sense for prototyping rather than production scale.
Step 1: Plan your backend needs
Before adding a backend, map out what you need. Five questions:
1. What data does your app store?
List the data types. "User profiles. Posts with text and optional image. Comments. Likes. Follow relationships." Specifics matter.
2. Who can access what data?
"Each user can only see their own posts." "All authenticated users can view public posts." "Only post authors can edit their posts." Define access rules upfront — Make uses them to set up Supabase Row Level Security policies.
3. Does your app need real users or fake users?
For early validation, fake user generation might be enough. For real testing, you need real auth flows. Decide which scenario applies before prompting Make.
4. Does your app integrate with external APIs?
OpenAI for AI features. Stripe for payments. SendGrid for email. List the integrations and note where API keys will need secure storage.
5. Are you using your existing Supabase project or starting fresh?
You can connect a Make file to an existing Supabase project (useful if you want to extend a prototype that already has user data) or create a new one (cleaner separation between prototypes).
These five answers shape the prompts you'll write next.
Step 2: Add a backend via prompt
The simplest way to add a backend is to prompt for it directly in the Make chat. Examples:
Add user authentication with email and password. Users should be able to sign up, log in, and recover passwords.
Add a database to store user posts. Each post has a title, body, optional image, and timestamp. Users can only see and edit their own posts.
Add file upload support so users can upload profile photos. Photos should be stored securely with access controls.
Make recommends adding a backend automatically when your prompt implies one. If you ask "let me see how this would work with real user data" without explicitly mentioning a backend, Make often suggests adding one.
The first time you add a backend to a Make file, Make prompts you to connect your Supabase account. Walk through the connection (Step 3 below), then Make handles the technical setup.
Once connected, Make:
- Sets up the database schema in your Supabase project
- Generates auth UI (login, signup, password reset forms)
- Wires up the frontend code to read/write from Supabase
- Creates the secure connection between the Make app and Supabase
You don't write SQL. You don't configure Supabase manually. Make handles the integration based on your prompts.
Step 3: Connect your Supabase account
The first time you add a backend, Make walks you through Supabase connection:
1. Sign in or create a Supabase account. If you have one, sign in. If not, Make links to Supabase signup.
2. Authorize Figma Make to access your Supabase organization. OAuth-style authorization. Make can create projects in your organization, not access existing ones unless you explicitly select them.
3. Choose a project. Create a new project for this Make file, or connect to an existing project. Each Make file connects to one Supabase project at a time.
4. Configure database region. Supabase projects have geographic regions. Pick the region closest to your users (US East, EU West, AP South, etc.).
Make remembers Supabase projects you've connected to. Subsequent Make files can reuse projects instead of creating new ones. This is useful when prototyping related features for the same product — they can share user data, auth, and stored content.
Account note
The Supabase account you connect doesn't have to match your Figma email. You can connect a personal Supabase account from a different email to a work Make file. This flexibility matters for individual contributors using their own Supabase free tier rather than the team's paid Supabase plan.
Step 4: Build auth flows
Once Supabase is connected, prompt Make to add auth:
Add email/password authentication. Generate a login page, signup page, and password reset flow.
Make generates the auth UI (forms, validation, error messaging) and wires it up to Supabase's auth API. You get working login and signup immediately.
For OAuth providers (Google, GitHub, etc.):
Add Google OAuth login alongside email/password.
Make configures the OAuth integration in Supabase and generates the appropriate UI. You'll need to provide OAuth client IDs and secrets — Make stores these securely in Supabase's secret storage.
Auth patterns to consider
- Email confirmation: Decide whether new users need to confirm email before accessing the app. Make can configure both flows; default behavior is email confirmation required.
- Password recovery: "Forgot password" flow generates email reset links. Make configures the email templates and the reset UI.
- Multi-factor auth: Available via Supabase but requires explicit setup. Prompt: "Add SMS-based MFA for high-security users."
- Magic link login: Passwordless login via email link. Often friendlier for prototypes — fewer fields, faster onboarding. Prompt: "Replace password login with magic link login."
For all auth flows, test the full user journey end-to-end. Test sign up, log in, log out, password reset, error states (invalid email, wrong password, expired token).
Step 5: Add database storage
Once auth is working, add database storage:
Add a database table for user posts. Each post should have title, body, optional image URL, created timestamp, and user_id. Users can read and edit only their own posts.
Make creates the database structure (a key-value store in most cases, scoped per user), configures Row Level Security (RLS) policies in Supabase, and wires the frontend to read/write data.
Important: Make uses Supabase's key-value pattern more often than full SQL schemas. This is faster to set up and works for most prototype patterns, but it's not equivalent to a properly-modeled production database. If your app needs complex SQL joins or aggregations, you may hit limitations.
Database patterns Make handles well
- User-scoped data: Each user's data is isolated and private.
- Public data: Data visible to all users (announcements, public profiles, marketplace listings).
- Shared data with permissions: Data shared between specific users (collaborator access, team data).
- Time-series data: Logs, activity feeds, history (with timestamps for ordering).
Database patterns that need extra work
- Complex many-to-many relationships: Make's key-value approach struggles with deeply relational data. May need manual SQL setup.
- Real-time subscriptions: Supabase supports real-time updates, but Make's integration is limited. Prompt explicitly for real-time features.
- Large-scale aggregations: Counting, summing, grouping across millions of records — Make may not generate optimized queries.
For most prototype use cases (small data volumes, simple relationships), Make's defaults work fine.
Step 6: Add file uploads
If your app needs file uploads:
Add image upload support for user profile photos. Photos should be stored in Supabase Storage with secure access — users can only upload their own photos but can view any user's public photo.
Make configures Supabase Storage buckets, sets up access policies, generates the upload UI (file picker, progress indicator, preview), and wires up the storage URLs.
Common file upload patterns Make handles:
- Profile photos: Single image per user, often with replace-existing behavior
- Post attachments: Multiple images per post, with reordering
- Document uploads: PDFs, Word docs, with metadata (filename, size, type)
- Voice notes or audio: Audio file uploads with playback UI
Storage on Supabase free tier is limited (1GB total across all storage buckets). For prototypes this is plenty. For production with active users uploading content, plan for paid Supabase.
Step 7: Use Edge Functions for custom logic
Edge Functions are serverless functions that run close to users. They're how you add custom backend logic to Make apps — API integrations, scheduled tasks, data transformations.
Common use cases:
1. Calling external APIs. Use Edge Functions to call OpenAI, Stripe, or other APIs without exposing your API keys client-side.
Add an Edge Function that calls the OpenAI API to summarize user posts. The API key should be stored securely as a Supabase secret.
2. Background processing. Heavy operations that shouldn't block the UI.
Add an Edge Function that processes uploaded images — resizes them and stores multiple sizes for responsive display.
3. Scheduled tasks. Operations that run on a schedule (daily summaries, weekly digests, cleanup tasks).
Add a daily Edge Function that emails users a summary of their previous day's activity.
4. Data transformations. Convert data between formats or aggregate it for display.
Make generates the Edge Function code, deploys it to Supabase, and wires up the frontend to call it. For complex Edge Functions, you may need to edit the generated code directly to handle edge cases.
Step 8: Use Vector embeddings for AI features
Vector embeddings enable AI-powered features in your Make app — semantic search, content recommendations, personalization, smart filters.
Add semantic search to my posts. Users should be able to search by meaning, not just keywords. Use vector embeddings stored in Supabase.
Make sets up the embedding pipeline:
- Generates embeddings for content (using OpenAI's embedding API or Supabase's local embedding model)
- Stores embeddings in Supabase's pgvector extension
- Configures the search query to use vector similarity
- Wires up the frontend search UI
Use cases that benefit:
- Smart search: "Find posts about productivity" returns posts even if they don't contain the word "productivity"
- Content recommendations: "Posts similar to this one" based on semantic similarity
- Smart filters: Filter content by themes or topics learned from the data
- AI-powered personalization: Recommend content based on a user's previous interactions
Vector embeddings require an embedding model (OpenAI, Cohere, local Supabase model). API keys for external embedding services should be stored as Supabase secrets.
Skip the trial-and-error
Mantlr lists Figma AI ecosystem guides — including Make tutorials, backend integration walkthroughs, MCP setup, and design system prep.
Browse Mantlr →
No signup required. Just curated resources.
Common backend setup mistakes
Five mistakes designers and founders make when adding backends to Make:
Mistake 1: Adding a backend before you need one. Backends complicate iteration. If you're still figuring out the UI and flow, skip the backend. Add it once the flow is stable.
Mistake 2: Not planning data access. "Users can see all data" might be your default, but it's rarely what you want. Define access rules (who can see what, who can edit what) before prompting for a backend.
Mistake 3: Confusing the backend env with production. Make's Supabase integration is meant for prototyping. Free tier limits, key-value patterns instead of full SQL, generated code that prioritizes speed over architecture — these are appropriate for prototypes, not for production-scale apps.
Mistake 4: Storing API keys in code. Never put API keys directly in Make's code. Use Supabase secret storage, called from Edge Functions. Make prompts for this correctly if you ask, but it's easy to accidentally inline keys during quick iterations.
Mistake 5: Not testing the full auth flow. Designers test login. They forget signup, password reset, expired tokens, sign-out, invalid credentials, etc. Test every state.
What you can't do with Figma Make's backend
The honest list:
1. Complex SQL schemas. Make uses Supabase as a key-value store in most cases. Production databases with normalized schemas, complex joins, and stored procedures need manual SQL work.
2. Production-scale architecture. Make's backend setup is optimized for prototype speed, not production scale. For real production, you'll need to refactor or rebuild on a properly-architected backend.
3. Custom backend frameworks. Make connects to Supabase. If your team uses a different backend (Firebase, custom Node.js, Ruby on Rails), Make doesn't integrate.
4. Local development. Make backends are deployed to Supabase from the start. You can't run a local Supabase instance for offline development.
5. Compliance-heavy use cases. Make's backend is fine for prototypes, but HIPAA, SOC 2, or PCI compliance requires more careful configuration than Make's defaults provide. If your app is compliance-bound, work with a real backend team.
For each of these, the workflow is: prototype in Make (fast), validate the idea (cheap), then rebuild on the right production stack with developer help.
Frequently asked questions
How do I add a backend to a Figma Make app?
Type a prompt like "Add user authentication" or "Add a database to store posts." Make recommends adding a Supabase backend, connects to your Supabase account, configures the database schema and auth flows, and wires up the frontend code. The setup takes minutes for most use cases.
Is the Figma Make backend free?
Make's backend integration with Supabase is free; Supabase itself has a free tier sufficient for most prototype workloads. Free tier limits: 500MB database, 1GB file storage, 2GB bandwidth, 50,000 monthly active users for auth. Production apps with real users will eventually need a paid Supabase plan.
Do I need to know SQL to use Figma Make's backend?
For most prototype use cases, no. Make generates the database setup from natural language prompts. For complex schemas, custom queries, or advanced patterns, SQL knowledge helps — but it's not required for basic prototype work.
Can I use my existing Supabase project with Figma Make?
Yes. When connecting Supabase to a Make file, you can either create a new project or connect to an existing one. Useful if you want to extend a prototype that already has user data or share data across multiple Make files.
What's stored in the Figma Make Supabase database?
By default, Make uses Supabase as a key-value store with data scoped per user. The structure isn't a traditional SQL schema — it's flexible JSON-like storage. For complex relational data, manual SQL setup is sometimes needed.
Can I use external APIs (OpenAI, Stripe) in Figma Make apps?
Yes, through Edge Functions. Store API keys in Supabase secret storage, then call them from Edge Functions. Never put API keys directly in Make's client-side code.
Is Figma Make's backend production-ready?
For prototypes and MVPs, yes. For production-scale apps with real users at scale, no. Make's backend is optimized for prototype speed. Real production usually requires rebuilding on properly-architected infrastructure.
Can I migrate a Figma Make backend to production later?
Yes, but it usually requires rebuilding. Make's backend code prioritizes speed over architecture. When you're ready for production, plan to migrate the data and rebuild the backend properly. Don't ship Make's backend code unchanged to production.
What happens to my Figma Make backend when I unpublish a Make file?
Unpublishing the Make file removes the public URL but doesn't delete the Supabase project. Your data persists in Supabase until you delete it manually. Useful for re-publishing later with the same data.
Where can I learn more about Figma Make?
Mantlr publishes Figma Make tutorials and integration guides weekly. See What Is Figma Make?, How to Use Figma Make, and How to Use Make Kits for more.
Build with Mantlr's curated library
You've added a backend. Your Make app now has real auth, data, and storage. The next step is shipping it to real users.
Mantlr lists 521 designer-vetted free design resources across 43 categories — every one license-verified, production-tested, free of email walls.
Browse Mantlr → · Subscribe to weekly editorial →
Related articles
If you're building working apps with Figma Make, these articles cover the connected workflow:
- What Is Figma Make? — The foundational article on Make.
- How to Use Figma Make — Full workflow walkthrough from blank file to published app.
- How to Use Make Kits in Figma Make — Design system integration.
- Figma Make Limitations — Honest framing of what Make can't do.
- The Complete Guide to Free Design Resources and AI Tools in 2026 — Mantlr's pillar guide to the full resource library.
About Mantlr Editorial
Mantlr is a free directory of designer-vetted, license-verified design resources. We test every resource before listing. No email walls. No paid placements. No affiliate dressing.
This article was written by Mantlr Editorial, the team behind a curated library of 521 free design resources. We work in production design daily and only recommend resources we'd use ourselves.
Last updated: December 5, 2026. Article reviewed quarterly for accuracy.