We killed our Figma integration

Early in the project, our ad creative pipeline pushed layered PSD-style designs into Figma, rendered them through the Figma plugin API, and pulled the exports back into Supabase Storage. It worked. It was also the most brittle part of the product, and it was the single biggest blocker on our roadmap.

The problems

• Figma is an amazing design tool and a mediocre image rendering service. Anything that was not a Figma-native layout fought the API.
• Every customer needed to install a plugin and grant a file-level token. That is a terrible first-run experience.
• We could not render images on a server schedule without a human-controlled Figma session open somewhere. The automation was fake.
• Debugging a rendering bug meant opening the file, re-running the plugin, and squinting at the layers. There was no reproducible CLI.

The replacement

We are building an in-house image editor around a server-side Skia renderer. The inputs are structured creative specs — headline, subhead, product image, brand tokens, layout preset — and the output is a PNG that nordenagent writes directly to Supabase Storage. No third-party dashboard, no plugin, no human in the loop, and — crucially — the exact same render produces the exact same image, every time.

The editor UI will be the part customers see: a focused canvas for creative iteration, grounded in the same token system the marketing site uses. That is the feature coming in Phase 6.

The lesson

It is extremely tempting to build on top of a polished product like Figma when you are moving fast. The right question is not whether the integration works today — it is whether it will still make sense when the feature it powers is load-bearing. For us the answer was no. Ripping it out cost us two weeks and unblocked the next six months.