With Payload in Figma Make, the content is real. Designers now design the content model, not just the screens.
Payload in Figma Make: the short answer for designers
Payload in Figma Make is a built-in backend for the apps and sites you prompt in Make. According to Figma's Payload in Figma announcement, published on 15 October 2026 at Config India, a single prompt can now set up a database, file storage, user login and an admin panel alongside the front end. Figma hosts it, it is available on all plans, and access is rolling out to every account over the coming weeks.
What does that change for designers? A Make prototype no longer has to be a beautiful shell with fake content. It can store real entries, accept form submissions, and hand a marketing team an admin panel at /admin where they edit copy and swap images without filing a ticket. The designer's job moves from "mock the content" to "design the content model". That is a bigger shift than it sounds, and this playbook walks through how to use it well.
What Figma actually shipped
Payload is an open-source headless CMS and application framework. Its team joined Figma in 2025, as covered in Figma's Payload joins Figma post. At Config India, Dylan Field's Config India recap confirmed that Payload's capabilities are now part of Figma Make.
Here is what the official posts state, and nothing more:
Backend from a prompt. Prompting in Make also sets up content and data tools: a database, file storage, user login and an admin panel.
CSV to collection. You can upload a CSV and ask the agent to turn its data into a Payload collection.
Admin panel for editors. Editors can create entries, edit copy, tag content, swap media, reorder categories, review versions and publish.
Permissions. Granular permissions control who can change what.
Secrets. API keys, for example for an email service, can be stored in Make's settings so visitors never see them.
Hosting. Hosting for Payload-backed Make projects is in beta and free for now. Figma says pricing and packaging will be announced before that free period ends.
Escape hatch. Developers can extend the app with Payload's open-source framework, and Figma says you can take the app outside Figma.
The examples in the announcement are useful because they are ordinary: a service site that collects driver applications and tracks them through onboarding, a companion site where custom fields drive a 3D shelf, a newsletter signup that sends confirmation emails. None of these are moonshots. They are the small, data-backed sites that used to need a developer for a week.
Hype vs reality
The hype version: designers can now ship full-stack products alone, and developers are optional. That is not what Figma claims, and it is not what a CMS does.
What holds up is narrower and still valuable. Content-driven sites, internal tools, signup flows and campaign microsites can now go from prompt to a working, editable product inside one tool. Marketing teams get a real editing surface instead of asking the designer to change a headline in a prototype. Version history and permissions come built in rather than bolted on.
What does not hold up yet: anything with complex business logic, payments, heavy integrations or strict compliance needs. The hosting is beta, the pricing is unknown, and the announcement lists no quotas or limits. If a client's revenue depends on the site, that uncertainty matters. The verdict: use Payload in Figma Make for content sites, pilots and internal tools now, and keep production apps with real transactions on a stack your engineers own, at least until pricing and limits are public.
Question | Static Make prototype | Make with Payload | Engineered web app |
|---|---|---|---|
Where content lives | Hardcoded in components | Payload collections, edited in | Your own database and CMS |
Who edits after launch | The designer, by prompting | Marketers and editors, with permissions | Editors, through a custom CMS |
Forms and submissions | Visual only | Stored and reviewable in the admin panel | Stored, validated, integrated with your systems |
User login | Not real | Included | Built to your security requirements |
Hosting and pricing | Make hosting | Beta, free for now, pricing to come | Your infrastructure, known costs |
Best for | Testing ideas and flows | Content sites, pilots, internal tools | Revenue-critical and regulated products |
The content-first prompt loop: how to use Payload in Figma Make
This is a four-step loop for designers. Call it the content-first prompt loop. The point is to design the data before the screens, because the data is now real.
Step 1: Write the content model before the prompt
List every content type the site needs and the fields each one has. A case study might have a title, client sector, cover image, summary, body and a "featured" toggle. A job listing might have a role, location, status and closing date. Name fields the way an editor would understand them, not the way a developer would.
Good writing pays off at this step. If you already use Figma Specs for designers to describe intent, put the content model in the spec so the Make agent and any developer read the same thing.
Step 2: Seed with real data, not lorem ipsum
Export a real spreadsheet: the actual team members, the actual products, the actual FAQs. Upload it as a CSV and ask the agent to create a Payload collection from it. Real data exposes the design problems early: the name that is three times longer than your mockup, the product with no image, the category with one item.
Step 3: Prompt the experience against the collection
Now prompt the screens, and refer to the collection by name: "Build a listing page from the Products collection, filter by category, and show the featured items first." Ask for empty states, long-text states and missing-image states explicitly. Agents tend to design the happy path unless told otherwise.
Step 4: Hand over the admin panel and watch someone use it
Open /admin with the person who will actually edit the site. Ask them to add an entry, change a cover image and publish. Note every field they misunderstand and rename it. Set permissions so a contributor cannot delete a collection. The admin panel is part of the product now, and it deserves the same usability check as the public pages.
Where it fails, and what to check before you ship
Run this checklist before any Payload-backed Make site goes in front of real users:
Forms. Confirm what happens on invalid input, and who gets notified when a submission arrives.
Personal data. Driver applications and signups are personal data. Check what you collect, why, and how long you keep it. Your legal obligations do not change because the backend was prompted.
Secrets. Every API key belongs in Make's settings, never in component code or a prompt.
Roles. Test the site logged in as each role, not only as the owner.
Exit plan. Decide now what happens if pricing does not fit. Figma says the app can leave Figma, so ask a developer to confirm that path for your project before launch.
If any of those answers are fuzzy, the site is still a prototype. That is fine, as long as everyone knows it.
Where this takes design work
Over the next one to three years, the line between "prototype" and "product" keeps fading for content-led work. Tools like Make with Payload, Framer skills for designers and agent-driven builders all push the same way: the designer who prompts the site also defines its data, its editing experience and its rules.
That makes content modelling, information architecture and editorial UX core design skills again. They never left, but they were often handed to whoever set up the CMS. Now the designer sets it up by describing it.
It also clarifies where engineers stay essential. The more a product depends on transactions, integrations, performance at scale or compliance, the more it needs custom web development rather than a hosted beta. The vibe coding vs professional development trade-off applies here exactly.
The fear: am I now expected to be a backend developer?
No. And the fear is understandable, because job descriptions tend to absorb every new tool the moment it ships.
The honest answer: you are expected to understand data, not to write database code. Knowing what a collection is, what a field type does, who should be allowed to edit what, and why personal data needs care is now part of shipping a site. That is learnable in a week of real use. It is closer to information architecture than to engineering.
What you should not do is promise production-grade apps from a beta tool. The designers who will do well with this are the ones who say clearly "this is a pilot" or "this needs an engineer", and who can explain why. If you want to go deeper into code, the design engineer path is open. If you do not, strong content and product thinking is still the skill these tools amplify.
FAQ
What is Payload in Figma Make?
Payload in Figma Make is a built-in backend, based on the open-source Payload CMS, that Figma added to Make on 15 October 2026. Prompting a project can set up a database, file storage, user login and an admin panel, hosted by Figma, so editors manage content at /admin without engineering help.
Is Payload in Figma Make free?
Payload is available on all Figma plans, rolling out over the coming weeks. Hosting for Payload-backed Make projects is in beta and free for now, and Figma says pricing and packaging will be announced before the free period ends.
Will Payload in Figma Make replace web developers?
No. It removes developer work for simple content sites, forms and internal tools. Products with payments, complex logic, integrations or compliance requirements still need engineers, and developers can extend Payload apps with its open-source framework.
Is Payload in Figma Make overhyped?
Partly. The claim that designers can now ship any full-stack product alone is overhyped. The real value is narrower: content-driven sites with a working admin panel, built and edited inside one tool. Treat it as production-ready only for low-risk projects until pricing and limits are published.
Can I move a Payload-backed Make app out of Figma?
Figma's announcement says you can take the app outside Figma, and Payload is open source with self-hosting options documented by the Payload team. Confirm the export path for your specific project with a developer before you rely on it.
Getting expert help
A prompted site with a real backend is a great way to test an idea quickly. Turning it into a dependable product is a different job: content modelling, permissions, data handling and a clean handover to engineering. If you want a team that designs and builds both sides, talk to a UI/UX agency in Casablanca that works with clients globally, or see DIGCY's web app development services. DIGCY is a Dribbble Selected Agency with 50+ projects delivered.
Let’s keep in touch.
Discover more about high-performance web design. Follow us on Twitter and Instagram.
