Figma Acquires Payload: A WordPress Developer's Excited Take 🎉

Yesterday, Figma announced they've acquired Payload, and I couldn't be more excited! As someone who's spent over 4 years deep in the WordPress ecosystem and recently started exploring Next.js with Payload, this news feels like the perfect storm of tools I use daily.

Why This Matters (Especially for WordPress Developers)

Let me start with some context. I've been building custom WordPress sites for years at Meta Digital, working with ACF (Advanced Custom Fields) to create flexible, client-friendly content management experiences. But recently, I've been diving into Next.js and Payload for modern web applications, and the developer experience has been refreshing.

When I read Figma's announcement, what stood out was their commitment to keeping Payload open-source. As someone who's built a career on open-source technologies like WordPress, this is huge. They're not just acquiring a product – they're investing in a community.

The Design-to-Development Pipeline Dream

Here's what really gets me excited: I use Figma every single day at work. Whether I'm translating designs into pixel-perfect WordPress themes or building Next.js components, Figma is my starting point. The idea of having a seamless pipeline from Figma design → Figma Sites → Payload CMS feels like the future of web development.

Figma's CTO Kris Rasmussen mentioned supporting "the entire spectrum of software development, from designers and developers to other collaborators." This resonates with my experience at Meta Digital, where successful projects happen when designers, developers, and clients can collaborate seamlessly.

The Beauty of Payload's Schema

Coming from WordPress, what immediately struck me about Payload was how elegant and powerful its schema definition is. Let me show you what I mean with a real example:

// A complete, flexible page schema in Payload
import { CollectionConfig } from 'payload/types';

export const Pages: CollectionConfig = {
  slug: 'pages',
  admin: {
    useAsTitle: 'title',
    defaultColumns: ['title', 'slug', 'updatedAt'],
  },
  access: {
    read: () => true,
  },
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'slug',
      type: 'text',
      admin: {
        position: 'sidebar',
      },
      hooks: {
        beforeValidate: [
          ({ value, originalDoc, data }) => {
            if (data?.title && !value) {
              return data.title.toLowerCase().replace(/ /g, '-');
            }
            return value;
          },
        ],
      },
    },
    {
      name: 'layout',
      type: 'blocks',
      blocks: [
        {
          slug: 'hero',
          fields: [
            {
              name: 'title',
              type: 'text',
              required: true,
            },
            {
              name: 'subtitle',
              type: 'textarea',
            },
            {
              name: 'backgroundImage',
              type: 'upload',
              relationTo: 'media',
            },
            {
              name: 'ctaButton',
              type: 'group',
              fields: [
                {
                  name: 'text',
                  type: 'text',
                },
                {
                  name: 'link',
                  type: 'text',
                },
              ],
            },
          ],
        },
        {
          slug: 'content',
          fields: [
            {
              name: 'richText',
              type: 'richText',
            },
          ],
        },
      ],
    },
  ],
};

That's it. This single configuration gives you:

• Auto-generated admin UI
• Type-safe API endpoints
• Flexible block-based content
• Built-in slug generation
• Image upload handling
• Rich text editing
• Automatic TypeScript types

The ACF Admin Interface Problem

Anyone who's worked extensively with ACF knows the pain: you spend hours in the WordPress admin clicking through field configurations, setting up flexible content layouts, and defining relationships. Then you export to PHP or JSON, hoping nothing breaks when you deploy.

The real frustration comes when you're debugging or need to make changes. You're jumping between your theme code and the WordPress admin interface, trying to remember which field name corresponds to what, and there's always that disconnect between what you see in the admin and what you're coding.

Even worse? Try explaining to a client why their staging site's fields don't match production because someone forgot to sync the field groups. Or debugging why a field isn't showing up, only to realize it was configured differently in the admin.

What I Love About This Transition

The difference is night and day. While WordPress + ACF has served me well for years, Payload brings:

• Everything in Code: No more clicking through admin interfaces to set up fields. Your schema lives in your codebase, gets committed to git, and deploys with your application.
• Automatic Type Generation: Payload generates TypeScript types from your schema automatically. No more guessing what properties are available or dealing with runtime errors.
• Version Control: Your entire content structure is version controlled. Need to see what fields were added last month? Check the git history.
• True Developer Experience: Hot reloading, better debugging, cleaner code, and IntelliSense that actually knows about your content structure.
• Local API Magic: Instead of making HTTP requests during development, Payload's Local API lets you query your data directly in your Next.js components. No network overhead, no API keys to manage locally - just clean, fast data fetching.
• Intuitive Admin UI: Clean, modern interface that clients actually enjoy using, generated from your code.

The Bigger Picture

What excites me most about Figma acquiring Payload isn't just the technical benefits – it's the philosophy alignment. Both companies understand that great products come from great developer experiences and strong communities.

Figma's commitment to keeping Payload open-source shows they get it. They're not trying to lock developers into a proprietary ecosystem; they're enhancing the tools we already love.

Looking Forward

As someone who's been building with WordPress for years and recently exploring the Next.js + Payload combination, this acquisition feels like validation of the direction modern web development is heading. The future is collaborative, type-safe, and developer-friendly.

I'm particularly excited about the upcoming Figma CMS integration. The thought of designing in Figma, prototyping interactions, and then seamlessly moving to a Payload-powered backend is exactly the kind of workflow improvement that makes our jobs more enjoyable and our clients happier.

What This Means for WordPress Developers

If you're a WordPress developer like me, don't see this as a threat to your skills. See it as an evolution. The content management principles we've mastered with WordPress – flexible fields, custom post types, user experience design – all translate beautifully to Payload.

The difference is that we get to work with modern tooling, better type safety, and a more enjoyable developer experience while maintaining the flexibility and power we love about WordPress.

---

What are your thoughts on Figma acquiring Payload? Are you excited about the potential integration between design and content management? I'd love to hear from fellow developers who are navigating similar transitions.