The prototype has an admin panel now

So what actually changed today?

At Config India in Bengaluru on October 15, Figma showed a lot: code layers moving into open beta, Figma Specs, a faster MCP server. The one we keep coming back to sounds smaller than it is. Figma Make now sets up a Payload backend on its own.

Ask Make for a site that stores or manages content, and Figma's help center says it designs the data model, creates the Payload collections, and builds the front end. Behind it you get a database, file storage, user login, APIs, and an admin panel. Figma hosts the whole thing. After you publish, your team can edit content in Make's CMS tab, or log in at the site's URL with /admin on the end.

Payload itself isn't new to Figma. The team joined in 2025. What's new is that Payload is now Make's native backend. Supabase stays available as a third-party connection, and existing Supabase-backed Make apps keep working as they do today.

The obvious bit, up front: TWIMCO's own site, these Field Notes included, runs on Payload CMS. So we're glad to see it here. It's also why the questions below are the ones we'd ask about any Payload site, not just one that started in Figma.

Is it a prototype or a real site now?

It can be both, and that's the point. Figma's launch post describes a designer prompting an experience with real content, a marketer adding and updating that content in the admin panel, and a developer customizing the app with Payload's open-source framework, with granular permissions over who can change what. The community recap says it more bluntly: turning a prototype into a production app.

For years the line was easy to see. The prototype lived in Figma. The real site lived somewhere with a database, logins, and a person who got the call when it broke. A client approved the prototype, then waited while someone rebuilt it properly.

That line just got blurry. A Make project can now hold records, drafts, versions, roles, and a URL people can visit. Which is great. It's also exactly how a prototype quietly becomes the production site without anyone deciding it should. Nobody signs off on "this is our website now." It just starts taking form submissions.

When is a Figma-hosted Make site enough?

More often than an agency might like to admit. If the site is mostly content your team updates, the data is low-stakes, and you could rebuild it in a month if you had to, a Make site on Figma hosting is a reasonable home. Think of:

• A campaign or launch page whose copy and images marketing changes every week.
• An event site with sessions, speakers, and a registration form.
• A directory or catalog, like the restaurant menu and places examples in Figma's help center.
• An internal tool or dashboard for a team that currently runs on a shared spreadsheet.

In those cases the win is real. Marketing stops filing tickets to change a headline. The designer sees the layout with real content instead of placeholder text. Nobody has to wire a separate CMS to a separate host on day one.

It gets less comfortable when the site is where money moves, where customers' personal data piles up, where search traffic is the business, or where the site has to talk to five other systems. That's not a knock on Payload. Those sites simply need answers the prototype was never asked for.

What still needs deciding before it's the real site?

Here's the list we'd walk through with a team before a Make project gets the real domain. None of it is exotic. These are the same calls you'd make for any Payload build. The difference is that Make lets you skip past them without noticing.

Who owns the content model. Make designs the data model from your prompt, and you change it by prompting again. Someone should own that model like a product decision: which collections exist, which fields are required, what "published" means. When a prompt renames a field on a site with live records, someone should know what happens to the data in that field before it happens, not after.

Where the data lives, and what it will cost. Figma hosts the app and its data. The help center says Payload backends are currently hosted in the eastern United States, with more regions coming. Hosting for Payload-backed Make projects is in beta and free, and Figma says it will announce pricing and packaging before that takes effect. Building with Payload also uses more AI credits than building without it. So budget for a number nobody knows yet, and decide now what you'd do if it doesn't fit.

How you'd leave. Payload is open source and self-hosts anywhere Node.js runs, and the generated Payload and Next.js code is included in the Make project. But GitHub integration and local development aren't available yet for Payload-backed Make apps; Figma says they're coming soon. Until they arrive, write down how you'd get the code, the records, and the media out, and who would do it. We made the same argument about leaving with your data when a vendor kills a feature. It applies to platforms you like, too.

Who can publish. Teammates on the same Figma plan can manage content, and permissions control who can view or change it. Decide who gets publish rights, who reviews drafts, and who removes access when someone leaves. Then ask who outside your Figma plan will need to edit, and how they'll get in.

Search and speed. If organic search matters, check the published site the way you'd check any site: titles and descriptions, URLs that won't change, a sitemap, redirects from the old site, and load time for your actual audience. One hosting region is fine for plenty of sites and a real question for others.

Integrations and keys. API keys go in Make's environment variable settings, where Figma stores them so visitors can't see them. That's the right pattern. Still list every key the site holds, what it can do, who can rotate it, and what breaks if it's revoked. The CRM, the email tool, the payment provider: each one is an edge someone should own.

Should we build in Make now, or wait?

Build. Just build with your eyes open. A team that prototypes with real content and a working admin panel will find the awkward fields, missing statuses, and confusing workflows weeks earlier than a team handing static screens to developers. That's worth having even if the Make project never becomes the final site.

The trap runs the other way: treating the prototype as the production plan because it already works. We wrote about this choice in AI app builder or engineering partner. The tools have moved a long way since. The question hasn't. Whoever builds it, someone has to own what happens after launch.

If you're also looking at code layers, the open beta lets you create and edit them free on paid plans through November 4, 2026, after which they use AI credits. Code layers and Make are different tools, but the same rule holds for both: a working prototype is a great brief. It isn't a signed-off architecture.

Spend an hour on this before the first real form goes live

If your team is about to try Make with Payload, here's the short version to settle first:

1. Name the site's job. Campaign, directory, internal tool, or the main site.
2. If it's the main site, name an owner for the content model and another for publishing rights.
3. Write the exit plan: where the code, records, and media would go, and who would move them.
4. Put a line in the budget for hosting once beta pricing is announced, plus a date to look at it again.
5. List the keys and integrations, with one owner for each.

When the answers come back "this is the real site now," that's the moment it deserves the same care as any other web application your business runs on: real roles, recovery paths, and admin controls built for the day the happy path ends. That part is our day job, and a good Make prototype is a fine place for it to start.

Related work: Howcast (publishing operation).