Banova — AI web builder
You describe a site in plain language, in Hebrew or English. Banova writes a real Next.js codebase, deploys it to Vercel and shows you the running site. A product I designed and built on my own, end to end.
- Scope
- Designed and built solo
- Pipeline
- Prompt → code → live deploy
- Status
- Live at banova.app
What it actually does
In the order a visitor experiences it:
- 01
You type what you want
In English or Hebrew. "A restaurant page with a menu and a contact form." The first three prompts need no account.
- 02
You watch it being written
The AI streams real code files onto the screen one at a time — not a progress bar, the actual files.
- 03
It gets published for real
The project is deployed to Vercel and comes back with a genuine web address you can open, share, or send to a client.
- 04
You keep talking to it
"Make the header blue." "Add my logo," with the image attached. Each change redeploys. You can also edit the code by hand, roll back a bad change, or export the whole thing as a ZIP.
The decision that separates it from a demo
Many AI builders show a simulated preview inside the browser. Banova works differently.
Every change is deployed to Vercel for real. A first build is live in about a minute or two, and what you see is the actual site that went live.
How it's built
The main parts:
AI code generation
The Claude API writes the project files, and they appear on screen as they are generated.
Checking the code before deploy
Generated code passes a validator and a syntax check before it is saved. If it fails, or the build fails on Vercel, the AI gets another attempt to fix it.
Real deployments
Each version is deployed to Vercel and gets its own working URL.
Accounts, usage and billing
Google sign-in, usage metered in tokens with limits enforced in the database, and Stripe subscriptions.
What it shows
In short:
- A full product built on my own, from the interface to deployment and payments.
- Hebrew and English, with full RTL support.
- Hands-on experience with how AI-generated code works, and where it breaks.
- Code editing in the browser, your own images attached in the chat, rolling back a bad change, and ZIP export.
Engineering highlights
The parts that were actually hard:
Billing a stream that might not finish
Usage is metered in tokens. Before the first byte, an atomic Postgres function reserves the worst case, so the limit holds even under concurrent requests. When the stream ends, completed, aborted or failed, the real usage is reconciled exactly once.
Payments that survive Stripe's retries
Stripe can deliver the same event twice, and out of order. The webhook is the only writer of subscription state, duplicates are dropped by event id, and an older event can never overwrite a newer one.
Parsing code from a stream that can be cut off
The parser tracks nesting instead of matching text, so a file that contains its own closing tag stays whole, and a stream cut off mid-file still yields a usable file. Deploys are serialized per project with a database lock, so autosaves never wait behind a build.
Stack
Next.js, React, TypeScript, Postgres, Stripe, the Claude API and Monaco for in-browser editing. Personal project: the code is private and available on request; the live site is linked above.
Does this sound like your app?
If your app has a similar problem, an audit is a low-risk way to start: read-only access, a written report and a prioritized list of fixes.