Qanvas helps you build a Next.js marketing site by conversation, export plain App Router code.
I built Qanvas for freelancers and small agencies who ship Next.js marketing sites for clients. It's a local app: you describe the site, an AI with your project's context (routes, content, assets, design tokens) builds and refines it with you, and a visual inspector handles quick layout, spacing and token tweaks without spending AI calls.
After a final decision to step into software creation full time, I want to rebuild some of my old sites. I did not want to have mess of porting components, and later die trying to maintain them. Anyway, all my sites more or less have the same base. I don't want anything manual, I don't want to get stuck in a SaaS web builder. So I made my own. I am not a fan of AI taking over art, but as far as coding goes, I have no issue with that. So I want AI to do the heavy lifting in coding while I focus on designing the product the way I want. Yet again, I need AI to do my bidding, than I have to do its bidding.
So what's special about Qanvas:
Runs on your own localhost. The full repo of the websites you create is 100% yours to deploy wherever you want.
You use your choice of Bring-Your-Own-Key AI agent (Google, Anthropic or OpenAI). Create an API key and use it safely for Qanvas. You pay your AI provider, not Qanvas.
Qanvas is not a subscription. Non-throttled full features for one project for free. One time lifetime fee of $99 only if you want unlimited projects.
Get started now: npx getqanvas --start (Node 22+). No account needed.
https://getqanvas.com (I built my site with Qanvas)
I'd like to know, for those who've used AI coding agents for landing pages, where did it go wrong for you? Does it matter to you that you directly integrate your AI agent of choice (and not using mine)? Do you like the idea of a fully exported Next.js repo that you can then deploy where you see fit, and thus you are not locked in to a SaaS platform?
Top comments (2)
The exported App Router repo is the differentiator for me; it keeps the builder from becoming another opaque deployment target. Where AI site builders usually fail is in broad changes that silently break a route, asset, or token convention. A reviewable change set—what files changed, which design tokens were touched, and a local preview/rollback point—would make the conversational workflow much easier to trust on real client sites.
Thank you and I agree... the export is the point. In the case of Qanvas, if it is gone, your exported site isn't. Let me give you a glimpse of what goes into the exported zip file:
On trust, some of this exists on Qanvas. The AI edits blocks (Hero, spotlight feature, grid, etc) rather than raw files. Every edit is checked against the block's schema and the registered design tokens, therefore a broken route, asset or token gets rejected before it reaches the draft. Unsaved changes survive a page reload, but nothing is written to disk until you hit Save. One Undo rolls back a whole AI turn.
On what you described: a reviewable change set, that's a good idea and I'm noting it.
If you'd like to try it:
npx getqanvas --start. The Community Edition has every feature (no throttling), and it is free for one project. Would appreciate hearing what you discover and think.