Going Beyond v0.app: How We Built an AI UI Generator for Vue and Nuxt (June 2025 Experiment)

Originally published in June 2025. Updated in September 2026.

This article records an experiment we ran in June 2025: building n0, an AI-powered UI generator for Vue and Nuxt, on top of the open-source bolt.diy project.

AI coding tools have changed a lot in the fifteen months since. v0.dev is now v0.app, Nuxt 4 is stable, and Nuxt UI is fully free. We've left the original story intact.

Where the facts have aged, you'll find clearly marked 2026 update notes, and there's a dedicated section on what still holds true and what doesn't.

What Is n0, and Why Did We Build It?

n0 is the internal AI-powered UI generator we built in June 2025 for Vue and Nuxt projects. It was based on an open-source alternative to v0.dev and combined best practices, custom prompts, and the Nuxt 4 project structure. Below, we show why we built it, how it worked, and how you can build something similar.

Why did we start with v0.dev?

We had been using v0.dev internally for some time, and we were pretty happy with the results. It let us generate proofs of concept and prototypes quickly, which we could then validate for both our internal initiatives and potential customers. The generated UI and functionality were excellent and made a great starting point for a new project.

v0.dev was created by Vercel, the company behind Next.js, a React framework for building server-side rendered and statically generated websites.

Source: Early version of v0.app

Because of that, v0.dev produced high-quality React and Next.js code but struggled to generate projects in other frameworks, such as Vue and Angular.

2026 update: v0.dev was rebranded as v0.app in August 2025 and repositioned as an agentic builder that plans, researches, and debugs over multiple steps. In February 2026, Vercel added GitHub repo import, a sandbox runtime, and a branch-and-pull-request workflow. But the framework focus hasn't changed: v0's FAQ still states that "v0 uses Next.js, React, TypeScript, Tailwind CSS, and shadcn/ui." For Vue and Nuxt teams, the gap described below still exists.

Why does v0 struggle with Vue and Nuxt?

At Monterail, we're closely tied to the Vue and Nuxt communities. We've delivered over 40 Vue projects and contribute to the ecosystem through initiatives such as the State of Vue report. We tried using v0.dev to generate projects, but we weren't happy with the results, so we looked for other tools for rapid prototyping. As official Vue and Nuxt Partners, we wanted a tool that matched our preferred frameworks and coding standards.

The limitations we ran into with v0.dev:

• It struggles to generate Vue/Nuxt code.

• It relies on assumptions and conventions from the React ecosystem.

• It gives little control over framework-specific best practices and project structure.

This isn't a criticism of v0. It's a natural result of a tool built by the team behind Next.js.

What alternatives to v0.dev did we explore?

The first tool that caught our attention was bolt.new, a tool from StackBlitz that helps JavaScript developers generate new projects and run them in the browser with StackBlitz. bolt.new is framework-agnostic, meaning it can generate projects with any modern tooling: React, Vue, Angular, Node.js, and more. The projects it generated were good, but after more in-depth research, we realized that the pricing and the generic nature of the tool weren't the best fit for us. We wanted something focused on Vue and Nuxt.

2026 update: bolt.new still uses token-based pricing: a free tier (1M tokens per month, 300K per day), Pro from $25/month, Teams at $30 per member per month, and custom Enterprise plans.

How Did We Build Our Own AI-Powered UI Generator?

We didn't build n0 from scratch. We forked an open-source project that already did the hard parts and focused our effort on Vue- and Nuxt-specific context. Rebuilding chat, attachments, code generation, and previews ourselves would have taken months, so we looked for an open-source foundation that we could shape to fit our needs.

That's when we found bolt.diy, the open-source version of bolt.new. It handles project generation, GitHub integration, chat, attachments, AI completion, and more. It was just what we needed!

Source: GitHub repository for bolt.diy

bolt.diy lets you plug in the LLM of your choice, including Anthropic Claude, Google Gemini, OpenAI, and many other providers. You can also customize both the application's UI and its functionality.

So we created n0 (the name is a work in progress), an alternative to v0.dev built specifically for Vue and Nuxt projects. Its system prompt follows best practices for SEO, performance, accessibility, and more.

Source: early version of Monterail's n0

How did we host n0 and control access?

We hosted n0 on Cloudflare, which at the time was the only platform bolt.diy supported. Because we were still testing it internally, we restricted access with Cloudflare Zero Trust until we were sure the project met all our needs.

Want to host your own version? This video tutorial on deploying bolt.diy to Cloudflare walks through it step by step.

2026 update: bolt.diy is no longer Cloudflare-only. According to its GitHub repository, you can now run it locally, in Docker, or as an Electron desktop app. It can deploy generated apps to Vercel, Netlify, or GitHub Pages, supports 19+ LLM providers, and integrates with the Model Context Protocol (MCP). The project is still actively maintained. One important caveat from the same README: the WebContainers API it runs on requires a commercial license for production use in a for-profit setting, although prototypes don't.

What's in the Monterail Nuxt Starter?

The Monterail Nuxt Starter is a public template that n0 used as the base for every generated project, so each prototype started with the same packages, structure, and conventions. We chose Nuxt as our default Vue framework because of its maturity, developer experience, and flexibility. Nuxt gives you the tools to build any kind of Vue project, from a simple single-page application (SPA) to a complex server-side rendered (SSR) app.

Our Monterail Nuxt Starter is publicly available. It comes with predefined packages such as Nuxt Image, Nuxt UI, Nuxt Fonts, and VueUse that we consider must-haves for all kinds of Vue/Nuxt projects.

Included out of the box (as of June 2025):

• @nuxt/image for optimized media

• @nuxt/ui (v2) for accessible UI components

• nuxt-fonts and vueuse for performance and utility

• A preconfigured project structure and best practices

Why did we use Nuxt UI v2 instead of v3?

You may have noticed that the starter uses Nuxt UI v2, the previous major version. That's because Nuxt UI 3 uses Tailwind CSS v4, which didn't work well with WASM (StackBlitz project generation) at the time. The project wouldn't build or run in a web container, even though it worked perfectly fine locally and in production. We decided to stick with v2 for the time being, since it works well with StackBlitz, and migrate to Nuxt UI 3 later.

We instructed n0 to always use this template, so that both the web container preview and the deployed instance worked as expected.

2026 update: A few things have moved here.

• Nuxt UI is now on v4. Nuxt UI v4, released in September 2025, merged Nuxt UI Pro into one free, open-source package with 110+ components, and it ships an MCP server so AI tools can read its docs directly. The Pro merge became possible after Vercel acquired NuxtLabs in July 2025.

• The Tailwind v4 blocker may no longer apply. Tailwind has since added an experimental WebAssembly build of its Oxide engine aimed at browser environments like StackBlitz. Test it in your own setup before migrating.

• The public starter hasn't been upgraded yet. As of this update, its package.json still pins nuxt ^3.16 and @nuxt/ui ^2.21, and Nuxt Fonts isn't listed among its dependencies. Nuxt 3 reached end of life on July 31, 2026, so treat the starter as a reference for structure and conventions, not as a base for new production projects.

How Do You Fine-Tune an LLM System Prompt for Nuxt?

You write down the rules your senior Vue developers already follow, phrase each one as a short, explicit instruction, and put them in the system prompt. bolt.diy's default system prompt is generic and meant for all kinds of modern web projects, so we knew right away we'd have to adapt it to Vue and Nuxt. Our experience with these frameworks told us which rules the LLM needed in order to build the projects we wanted.

Here are the rules we wrote for the system prompt in June 2025. We kept refining them with each iteration to improve the prototypes.

<nuxt_best_practices>

  1. Use pnpm for all dependency installation and management.

  2. Use NuxtImg for images: modern formats, lazy loading, width/height set.

  3. Use NuxtLink for internal navigation.

  4. Do not write imports for Vue utils (ref, reactive, computed, watch) in script setup blocks—they are auto-imported.

  5. Use Nuxt UI components (UButton, UInput, USelect, etc.) for consistent, accessible design.

  6. Separate the app by pages based on context.

  7. Keep files under 100 lines; split into smaller files if needed.

  8. Extract reusable logic into composables (e.g., useCounter), never use the word "Store".

  9. Use Nuxt's useFetch for data fetching (SSR/client hydration), handle loading/error/data states, and mock data if needed.

  10. Use useHead for page title/meta tags.

  11. Use Nuxt layout components for page structure.

  12. Place all new components, pages, and composables in the app folder (Nuxt 4+ syntax).

  13. Write complete, copy-pasteable Vue component code.

  14. All code must be accessible and follow best practices.

  15. Remove unused imports; do not import auto-imported components/composables/utils.

  16. Create reusable components for logic like modals/forms; do not place such logic in pages.

  17. Each component, page, or composable must be in its own file.

  18. Wrap Nuxt UI components in custom components for reusability and consistent behavior.

  19. Keep as much logic as possible in composables, not components; components should focus on UI.

  20. Avoid logic in pages—move to composables/components. Only SEO logic belongs in pages.

  21. Use components in pages/layouts for maintainability and clarity.

  22. Always use Nuxt 4+ compatible syntax for all new code.

</nuxt_best_practices>

You're welcome to apply these rules to your own projects. They steer the model toward the software quality, proven patterns, and conventions we expect, so Vue/Nuxt developers can jump into a generated project without first untangling it. The same principle applies to AI coding assistants in general.

What Still Holds True, and What's Outdated Since June 2025?

The idea behind n0 has aged well. The specific tools and versions have not. Framework-specific context still decides whether AI-generated Vue code is usable, but the way you deliver that context has changed. The table below goes through each claim from the original article.

How would we deliver the same context today?

In 2026, you don't have to put everything in one system prompt anymore. Nuxt now provides an official Nuxt MCP server, and Nuxt UI has its own MCP server. Both let AI assistants such as Claude Code and Cursor pull current documentation and component metadata on demand. A setup that works well today looks like this:

• Rules (like the 22 above) in the tool's rules or instructions file, for your team's conventions.

• MCP servers for up-to-date framework and component knowledge, so the model doesn't rely on outdated training data.

• A maintained starter on Nuxt 4 and Nuxt UI v4, so every generated project starts from a known-good base.

This is part of the wider shift from chat-based generators toward agentic development environments.

Should You Build Your Own AI Prototyping Tool or Use an Off-the-Shelf One?

Build your own only when a framework standard or a data-privacy requirement makes off-the-shelf tools slower than maintaining a fork. That was our situation in June 2025. A self-hosted generator isn't free, though, and the costs are easy to underestimate:

• Licensing: bolt.diy runs on StackBlitz's WebContainers, which require a commercial license for for-profit production use.

• Model costs: You bring your own LLM API keys, so usage costs grow with every prompt your team sends.

• Prompt and starter upkeep: Rules and templates age as fast as the frameworks do. Our own starter shows this, since it still runs on Nuxt 3.

• Access and security: An internal tool needs authentication (we used Cloudflare Zero Trust) and a policy for what code and data it can see.

• Code quality at handoff: A prototype that looks finished is not a production codebase. Plan for a review and hardening step before generated code ships.

If none of these requirements apply to you, there are other options like, for example, an off-the-shelf tool with good rules files. 

How Can AI-Powered UI Tools Speed Up Prototyping for Vue Teams?

AI UI generators let a team test an idea in minutes instead of days, as long as the output follows the team's own standards. That's the lesson of n0, and it has held up even as the tools changed. With bolt.diy, anyone could build their own v0-style tool: clone the project, add your LLM and system prompt rules, and you're ready to go. Today, rules files, MCP servers, and agentic assistants make the same approach even easier to set up.

The hard part was never the generator. It was knowing which conventions to encode and what happens to a prototype once it works. If you'd like help with that, from rapid prototyping to fast-tracking an MVP with AI to scaling a production Vue or Nuxt app, our team would be glad to talk it through with you.