How VULK Handles 8 Platforms from One Conversation

Esther Howard's avatar

João Castro

blog-details-cover

The problem nobody else wanted to solve

When I started building VULK, every AI code builder on the market generated the same thing: a React app with Tailwind CSS. Bolt, v0, Lovable, Replit -- all of them. If you wanted a mobile app, a Shopify theme, a Laravel backend, or a browser game, you were out of luck. The entire category had decided that "AI builds apps" meant "AI builds React apps."

That never made sense to me. The developer world is far bigger than React. There are 1.7 million Shopify merchants who need custom themes. Flutter has over a million active developers building native mobile apps. PHP still powers 77% of the web. Three.js is the standard for browser-based 3D. These are massive communities, and they were being completely ignored.

So I built VULK to handle all of them. One conversation, 8 platforms:

  1. React + Vite -- Web apps with Tailwind CSS
  2. Flutter -- Native mobile apps with Clean Architecture
  3. React Native + Expo -- Cross-platform mobile with NativeWind
  4. Shopify Liquid Themes -- Online Store 2.0
  5. Shopify Apps -- Remix + App Bridge + Polaris
  6. Shopify Hydrogen -- Headless commerce storefronts
  7. PHP / Laravel -- Server-side applications
  8. Three.js -- Browser games with physics engines

How the detection actually works under the hood

Here is the part that most people are curious about. You do not pick a platform from a dropdown. You just describe what you want, and VULK figures out which generation mode to activate.

Before your prompt reaches the AI model, our detection system scans it for platform-specific signals. These are not just naive keyword matches -- the system weighs context, co-occurring terms, and intent patterns. For example, "build an app with screens and a bottom navigation bar" signals mobile, not web. "Build a store with product variants and collections" signals Shopify, not generic e-commerce.

The detection follows a strict priority order, and there is a reason for that: Shopify App > Shopify Hydrogen > Shopify Liquid > Flutter > React Native > Three.js > PHP/Laravel > React (default).

Why this order? Because specificity should win. If someone mentions "Shopify app," that is a very precise intent -- they want a Remix-based merchant app with App Bridge and Polaris, not a generic web app that happens to integrate with Shopify. The more specialized the platform, the higher its priority. React sits at the bottom because it is the catch-all. If nothing else matches, you probably want a web app, and React + Vite is the best default for that.

Here is what triggers each mode:

  • Flutter -- "mobile app," "Flutter," "iOS and Android," "native app," "APK," "screens" (not "pages")
  • React Native -- "React Native," "Expo," "cross-platform mobile"
  • Shopify Liquid -- "Shopify theme," "online store," "Shopify store"
  • Shopify Apps -- "Shopify app," "app for merchants," "Shopify plugin"
  • Shopify Hydrogen -- "Hydrogen," "headless Shopify," "Storefront API"
  • PHP/Laravel -- "PHP," "Laravel," "WordPress," "server-side"
  • Three.js -- "game," "3D," "Three.js," "browser game"
  • React -- Everything else

If you ever want to override the detection, just be explicit. "Build this in Flutter" or "Use React for this" always wins.

What makes each mode actually different

This is not just swapping one template for another. Each platform has its own generation pipeline with four distinct layers, and getting each one right took months of engineering.

Prompt engineering -- Every platform has its own system prompt that teaches the AI model the conventions, patterns, and best practices for that stack. The Shopify prompt alone is over 2,100 lines. It covers Liquid syntax, section schemas, Dawn compatibility, metafield patterns, and the dozens of quirks that separate a working theme from one that breaks in Shopify's theme editor. The Flutter prompt enforces Clean Architecture. The Three.js prompt handles game loops, collision detection, and physics integration. You cannot just tell a model "write Shopify code" and expect good output. You need deep, platform-specific prompt engineering.

File structure -- React generates src/components/ and src/pages/. Flutter generates lib/models/, lib/screens/, and lib/services/. Shopify generates sections/, templates/, and assets/. Laravel generates app/Http/Controllers/, resources/views/, and database/migrations/. Each framework has expectations about where code lives, and violating those expectations makes the output useless to experienced developers.

Preview rendering -- This is where the engineering gets genuinely hard. React uses a Vite dev server in a sandboxed container. Flutter compiles to Flutter Web in the browser. Shopify Liquid uses a custom rendering engine we built from scratch -- it parses Liquid templates, injects mock product data, and renders them visually so you can see your theme before uploading it to Shopify. Three.js renders directly in a canvas element. Each renderer has its own compilation pipeline, error handling, and hot-reload behavior.

Deployment -- React deploys to Cloudflare Pages with one click. Flutter exports a real APK file. Shopify themes can be downloaded and pushed via the Shopify CLI. Laravel projects download as complete project directories ready for any PHP host.

The honest comparison

I am going to be direct about what the competitive landscape looks like, because I think developers deserve transparency:

| | React | Flutter | React Native | Shopify | PHP | Games | |---|---|---|---|---|---|---| | Bolt | Yes | No | No | No | No | No | | v0 | Yes | No | No | No | No | No | | Lovable | Yes | No | No | No | No | No | | Replit | Yes | No | Partial | No | No | No | | VULK | Yes | Yes | Yes | Yes (3 modes) | Yes | Yes |

This is not incremental. It is categorical. The gap exists because multi-platform generation is genuinely hard to build. Every new platform multiplies the engineering work: new prompt engineering, new file structure logic, new preview rendering, new deployment pipeline, new testing surface. And each platform has to produce output that an experienced developer in that ecosystem would consider acceptable. A Flutter developer will immediately spot a poorly structured Dart project. A Shopify developer will know if the Liquid templates do not follow Online Store 2.0 patterns.

Why nobody else does this

I have thought about this a lot, and I believe the answer is straightforward: the economics do not look attractive at first glance.

If you are building an AI code builder and 80% of your users want React apps, the obvious business decision is to make React generation really good and ignore everything else. Adding Flutter support means months of engineering work that serves maybe 5% of your user base. Adding Shopify serves maybe 3%. The ROI per platform decreases.

But here is what that analysis misses: those smaller communities have almost zero alternatives. A React developer can choose between five or six AI builders. A Shopify developer who wants to generate a custom theme with AI has one option. A Flutter developer who wants to go from prompt to APK has one option. The competitive moat in those categories is enormous precisely because no one else wants to invest in building it.

I also believe the developer world is moving toward specialization, not consolidation. People are building for more platforms, not fewer. Mobile-first is standard. E-commerce is growing. Browser-based games and 3D experiences are mainstream. A tool that only generates React is going to feel increasingly limited.

Try it yourself

Go to vulk.dev and try these prompts:

  • "Build a fitness tracking mobile app with workout logging" -- triggers Flutter
  • "Create a minimal Shopify theme for a coffee brand" -- triggers Liquid
  • "Build a 3D endless runner game with obstacles" -- triggers Three.js
  • "Create a Laravel REST API for task management" -- triggers PHP
  • "Build a SaaS analytics dashboard with charts" -- triggers React

No configuration. No dropdown menus. Just describe what you want, and the right platform activates automatically. That is the experience I wanted to build from day one.

この投稿をシェア
コメント
Esther Howard's avatar

Esther Howard

Until recently, the prevailing view assumed lorem ipsum was born as a nonsense text. It's not Latin though it looks like nothing.

返信

プロダクトの更新情報とヒントを受け取る

新機能、AIモデルのアップデート、開発のヒントを直接お届けします。

  • スパムは送りません

  • いつでも配信停止

  • プロダクトの更新情報 & ヒント