The Part of Shipping a Figma Plugin That Figma Can't Help You With

Shipping a Figma plugin feels like crossing a finish line. The code works. The review passed. The listing is live. You close your laptop and feel genuinely pleased with yourself for about twelve hours. Then you wake up and realize the listing has three views, zero installs, and your icon looks like a gray blob in the browser tab of your half-built product page. That gap between "plugin is live" and "plugin is actually a product" is what this post is about.

The plugin itself is the easy part. What nobody warns you about is everything that comes after the tool exists. The cover art, the web presence, the icon formats that nobody told you your companion site needed. I figured all of this out slowly, mostly by shipping something undercooked and watching the numbers tell me exactly what I had missed. Here is what I learned.

Your Plugin Listing Is a Product Page, Not a Readme

The Figma plugin marketplace is a shop front. People scroll through it the same way they scroll through the App Store. Nobody reads the description first. They look at the cover image, they glance at the icon, and they either stop or keep moving. You have about a second of attention before someone scrolls past. Design for the thumbnail, not the full resolution.

The cover image spec Figma expects is 1920 by 960 pixels. That sounds generous until you see how small it renders in the listing grid. Pack too much into that canvas and you end up with a wall of text that nobody can parse at listing size. I made that mistake on my first plugin and only noticed when I checked the grid view on a different device.

Things I got wrong on that first listing:

• Putting too much text in the cover image, which became unreadable at thumbnail size
• Using a mockup that looked sharp on my display but muddy on standard-resolution screens
• Treating the plugin icon as an afterthought rather than a core asset
• Not testing the icon against Figma's dark interface before submitting

The icon point is worth holding on to. Your plugin icon shows up in the Figma toolbar after installation. It shows up in the user's recently used list. It follows the tool everywhere. A 128 by 128 pixel square that reads cleanly on a white background may look completely wrong against Figma's dark canvas. Test both modes. Submit only after testing both modes.

A Web Presence Is Not Optional, Even a Minimal One

You do not need a full marketing site. But you do need somewhere for people to land that is not the Figma marketplace listing. A product page, a simple single-pager, something with your URL on it that you control. The listing is a starting point, not a destination for users who want to understand what they are installing.

Here is why a basic web presence actually matters:

• Your listing description has a character limit and gives you no control over typography or visual hierarchy
• You cannot run analytics on the Figma marketplace page
• When someone shares your plugin on social media, the link preview pulls from your og:image tag, and if you have nothing set, the fallback is usually something embarrassing
• People who want to trust a tool will search for the maker, and finding nothing is a trust signal in the wrong direction

That last item surprised me. I noticed a measurable difference in installs once I added even a minimal page. Not because every user visits before installing. But some do, especially the more discerning ones who think carefully about what they add to their Figma workspace. When they find nothing, they leave.

Building the page itself is outside what this post covers. What caught me off guard was the asset prep once the page existed. Favicon. Apple touch icon. Open Graph image. Web app manifest. Social card images. None of it is glamorous, but all of it is felt in its absence. If you are adding a web app manifest, it is worth reading how icon purpose values work in the W3C specification before you wire up your icons. The purpose field is where most of the confusion starts, and the spec is clearer than any Stack Overflow thread you will find on the subject.

Getting the Icon Formats Right Before You Launch

This is the part that took me longest to sort out, and it is more specific than it looks from the outside. Here is the prep order that made the most sense once I had done it badly a few times:

1. Start with a master SVG at a square aspect ratio with no embedded raster images
2. Export a 512 by 512 PNG as your base raster asset
3. Resize down to 192, 180, 64, 48, and 32 pixels
4. Generate your favicon.ico from the 32 and 48 pixel versions
5. Use the 180 pixel version as your apple-touch-icon
6. Create a maskable variant for your web app manifest

That last step is the one that bit me hardest. I added a basic web app manifest to my plugin's companion site because I wanted it to feel polished when someone saved it to their phone home screen. I assumed dropping in a PNG and pointing the manifest at it was enough. It was not.

Android does not agree with that assumption. Android uses adaptive icons, which means the operating system clips your icon into a shape based on the device. Circle, squircle, rounded rectangle, the device decides. If your logo is centered on a full-bleed background, you might survive this. But if your icon design assumes transparent edges, or if the meaningful content sits close to the border, the result on an Android home screen looks genuinely broken.

The solution is a maskable icon. It is a version of your icon where the meaningful content sits inside a safe zone, roughly the central 80 percent of the image area, so the OS can clip the edges without destroying anything important. You declare it in your manifest with purpose: maskable on the relevant icon entry. Running your icon through a maskable icon generator before adding it to your manifest takes about two minutes and shows you exactly how different mask shapes will crop your artwork. That two minutes saved me from shipping something that looked broken on every Android device that tried to add it to a home screen.

This is one of those problems that is invisible until it is not. Nobody tests their plugin companion site on an Android home screen during development. I did not. But some users do, and those users notice immediately.

What Shipping Actually Taught Me About the Stuff Around the Thing

The plugin is the product. The assets around it are the packaging. Nobody reaches for a jar of sauce because the sauce is visible through the glass. They reach for it because the label caught their eye, the name made sense, and the brand did not look neglected. The contents and the container are different problems, and both need solving before you ship.

Indie plugin makers tend to spend months on the tool and hours on the packaging. That ratio is probably wrong, at least for a first release. The code being good is the floor, not the ceiling. The listing, the page, the icons, the preview images: these are what most users encounter before they ever install your plugin. First impressions happen before the first click, and a gray blob in a browser tab is a first impression.

I figured all of this out by shipping something undercooked, watching the numbers, and fixing things one at a time. The cover art came first, then the web page, then the favicon situation that eventually led me to the maskable icon problem I did not know existed. Each of those felt like a detour from the real work. In hindsight, it was all the real work. The plugin existed. Making it feel like a product that someone could trust took longer than building the plugin itself.

Start with the cover art. Test the icon in dark mode before submitting. Build even a minimal web presence with proper metadata and a correctly prepared manifest. None of this is the part of plugin development anyone talks about. It is the part that determines whether the thing you built gets a real chance.