DEV Community: Naji Amer

We Built an AI Vision Plugin That Converts Figma to Semantic Tailwind, Payload CMS, and Astro

Naji Amer — Sun, 31 May 2026 15:34:55 +0000

Most "Figma to HTML" or "Figma to React" exporters generate unmaintainable, absolute-positioned garbage. You end up spending more time stripping out the bloated code, styling overrides, and inline styles than you would have spent just writing it from scratch.

We wanted to see if we could use advanced AI vision models to look at visual hierarchies, interpret Figma Auto Layouts natively, and compile them straight into pure, responsive Tailwind utilities and structured backend schemas.

So we built a dedicated ecosystem to handle it at studio.nextmark.ae. Here is a look under the hood at how it processes frontend and backend architecture.

🧠 The Core Engine: AI Vision vs. Naive Code Exporters

Traditional plugins read raw Figma node JSON trees. If a designer accidentally groups layers poorly, the exported code breaks.

Our approach pairs Figma node structural data with state-of-the-art AI Vision models. The engine physically "sees" the visual layout to accurately infer mobile constraints, alignment patterns, and spacing intents.

Flexbox & Grid Native: Instead of absolute coordinates (top: 42px; left: 110px;), the compiler identifies structural containers and converts Figma Auto Layout properties directly into robust CSS Flex and CSS Grid classes.
Pure Tailwind Utilities Only: The system generates 100% standard Tailwind CSS classes (e.g., flex items-center gap-4 md:grid-cols-3). There are zero proprietary CSS files, zero inline styles, and no configuration wrapper overrides.
Auto-Responsive Inferences: The vision model evaluates how a layout should collapse on smaller viewports, automatically injecting baseline responsive modifiers (sm:, md:, lg:) right into the HTML output.

🔌 Bridging the Full-Stack Gap (Astro & Payload CMS)

Generating a basic HTML file doesn't help if you're building a modern headless website. You still have to break that HTML into components and write database schemas manually. We engineered the platform to map visual blocks straight into development setups:

Modular Astro Components: The tool outputs clean component structures and reusable markup ready to drop directly into an Astro page hierarchy.
Typed Payload CMS Blocks: For teams running headless architectures, it converts the generated UI into reusable Payload blocks with strictly typed TypeScript fields. It skips the repetitive, manual chore of coding schemas for custom grids or sliders.

🛠️ The Interactive Iteration Loop

AI conversions are rarely 100% perfect on the first pass. Instead of forcing developers to jump back into the IDE to fix minor discrepancies, we built an AI Code Refinement layer directly into the dashboard.

<!-- Example of the initial clean container output -->
<div class="flex flex-col gap-6 p-6 bg-slate-900 rounded-xl">
  <h3 class="text-xl font-bold text-white">Interactive Component</h3>
  <p class="text-sm text-slate-400">Pure Tailwind utility classes with zero inline styling bloat.</p>
</div>

If a column gap or font weight feels slightly off, you can text-prompt the internal engine (e.g., "Change the card to a 3-column grid on desktop and fix the column gap"). The code updates in real-time, rewriting only the necessary utility classes without breaking the surrounding semantic structure.

📦 Test the Live Sandbox

We want the code quality to speak for itself. You can copy-paste components, review the output structures, and check the responsive layouts live.

👉 Try the Plugin Interface at studio.nextmark.ae

How is your team currently handling the design-to-code handoff? Are you using native exporters, or are you still translating margins and typography manually? Let's discuss front-end optimization in the comments!

The Invasive Part of Sentry That No One Wants to Talk About

Naji Amer — Sat, 16 May 2026 18:57:46 +0000

You know the drill. You spin up a fresh project, tweak your Tailwind config until it looks just right, and get ready to push to prod. But wait! You can’t fly blind. You need an error tracker.

Types npm install @sentry/react. Boom. Done. You are a responsible, proactive engineer.

But have you ever actually paused to look at the network tab to see what you just deployed? We like to tell ourselves that we just installed a harmless little crash logger. But if we are being completely honest, we have essentially normalized embedding commercial surveillance camera into our users' browsers—and nobody seems to want to talk about it!

The "It's Just Logging Errors, Right?" Myth

It is not just patiently sitting in the corner waiting for a TypeError to happen. It is aggressively taking notes on ... everything.

And... Things Got... Artificial

This massive data collection was already a bit of a privacy tightrope, but then the AI boom happened.

Sentry (like everyone else) aggressively integrated AI into their platform, launching tools like their "Seer" autofix agent and AI-generated Replay Summaries.

Why does this matter? Because when an error occurs now, your user's breadcrumbs, their browser state, and the network request context are no longer just sitting quietly in a secure database log waiting for a human to review them. They are being bundled up and fed directly into an LLM’s context window so the AI can generate a helpful GitHub Pull Request or summarize why the user rage-clicked a button.

Privacy... Hmmm...

Let’s be real for a second: we allow this commercial surveillance because debugging modern frontend apps is an absolute nightmare.

When a user submits a support ticket saying, "The checkout button doesn't work, fix it," with zero context, standard error logs are useless. We would gladly hand over our firstborn to watch a Session Replay of that exact bug instead of spending three days trying to blindly recreate a bizarre React hydration state issue.

The ultimate irony?

Most of us don't even need these tools in the first place. If you are running a massive enterprise SaaS or a banking app with millions of dollars on the line, sure, the trade-off makes sense. But for the vast majority of our side projects, MVPs, and standard CRUD apps, standard server logs and a simple React error boundary are more than enough. We are blindly installing enterprise-grade surveillance just because a tutorial told us it was "best practice."

We’ve officially left the doors wide open and handed the data over to the AI overlords. Now, let’s just sit back and see exactly how hard this is going to bite us back.

I built an open-source Shopify alternative with Next.js 16 & PayloadCMS

Naji Amer — Mon, 16 Feb 2026 10:35:40 +0000

For the last decade, building an e-commerce site has felt like choosing between two evils:

The "SaaS Trap" (Shopify): You get a nice dashboard, but you pay a monthly sub + a "transaction fee" on every sale. Want to customize checkout? That’ll be $2,000/month for an Enterprise plan, please.

The "Plugin Hell" (WooCommerce/Magento): You own the code, but you spend 50% of your time fighting conflicting plugins, security patches, and slow PHP server response times.

I believed there had to be a third way. A way that combines the DX (Developer Experience) of Next.js with the content management power of a headless CMS—without the bloat.

So, I built Amerta.

It is an MIT Licensed, open-source e-commerce standard built on PayloadCMS 3.7 and Next.js 16.

Here is why (and how) I built it.

🛠 The Stack

Framework: Next.js 16 (App Router, Server Components)
CMS: PayloadCMS 3.0 (Headless, TypeScript-first)
Database: MongoDB
Styling: TailwindCSS
Deployment: Self-host (Docker/VPS) or Cloud (Vercel/Neon)

The "Local API" Architecture (No Fetch Overhead)
The biggest bottleneck in headless e-commerce is usually the HTTP requests between your frontend and your CMS.

Because PayloadCMS 3.0 supports the Local API, Amerta doesn't need to send HTTP requests to fetch products. Since Payload runs alongside Next.js in the same server instance, we query the database directly.

Traditional Headless:
Next.js (Server) -> HTTP Request -> Headless CMS -> DB

Amerta (Local API):
Next.js (Server) -> Direct Function Call -> DB

This means zero network latency for data fetching.

Global by Default (Not a Plugin)
Most platforms treat Multi-Currency and Localization as expensive plugins. I treated them as requirements.
RTL Support: Native. The layout flips automatically based on the locale (great for MENA regions).
Multi-Currency: Support for dynamic pricing (AED, USD, EUR) without relying on third-party scripts that slow down the DOM.
The "SaaS Tax" is Gone
This is the main reason I open-sourced this.
When you use SaaS platforms, you often pay a % fee on every transaction on top of Stripe/PayPal fees.

With Amerta:

Bring Your Own Keys: Plug in your Stripe/Mamo keys directly.
Self-Host: Put it on a $5 DigitalOcean droplet or deploy to Railway.
No Limits: 100 products or 100,000 products. You don't pay per SKU.

Built for the "Next" Era

Try it out

I built this because I wanted to give developers a way to build custom, high-performance stores without being locked into a vendor's ecosystem.

It’s open source. It’s free. It’s yours to break, fork, and monetize.

🌟 Star the Repo
🚀 View the Demo

Let me know what you think in the comments! I'm actively looking for contributors.