What "a website in 30 seconds" actually costs to build
ChittoWeb turns a sentence into a published website. Generating the page is the easy part. Everything that makes it survive the second edit is not.
Everyone has seen the demo by now. You type "a menu page for my momo shop in Thamel", wait, and a website appears. It looks like magic, and the magic is the least interesting part of the system.
We built ChittoWeb for the Nepali market, where most small businesses have no technical team and no budget for one. Getting a model to emit React components is close to a solved problem. Getting a business owner in Pokhara to a site they can actually run, on a connection that drops, is not.
The generation is the cheap part
A language model producing a plausible landing page is table stakes. The problems start immediately after.
Output is not deterministic, but a business is. Ask for the same site twice and you get two different sites. That is fine for a demo and unacceptable for a customer who has already printed the URL on a signboard. The system has to treat the first generation as a seed and everything after as an edit to a known state.
Edits are where naive systems fall apart. A user says "make the header smaller". If you regenerate the page, the header shrinks and their carefully-worded About text silently changes wording, because the model rewrote it on the way past. The customer did not ask for that. They will not notice for a week, and when they do they will not trust the tool again.
Surgical edits need a dependency graph
Our answer is a dependency graph over the generated project. Every component, style token and content block is a node; edges record what depends on what. When an edit request comes in, we resolve which nodes it can legitimately touch and hand the model only those, with the rest frozen.
The effect is boring in the best way. "Make the header smaller" changes the header. It does not touch the About text, because the About text is not reachable from that request.
This is also what makes the output auditable. When something does change, we can say which node changed and why, rather than shrugging at a diff across the whole project.
Deployment is a product decision, not an afterthought
A generated site that lives on a preview URL is a toy. The value only appears when it is on a real domain, loading fast for someone on mobile data in Nepal.
We deploy to Cloudflare's edge, with assets on R2. That is not brand loyalty. It is the shortest path between a static build and a point of presence that responds quickly to Nepali traffic, without us running servers.
Domains matter more than people expect. A .com.np domain carries a specific kind of local credibility. Wiring custom domain provisioning into the flow, rather than sending the user to a registrar and hoping, is a large part of why sites actually go live instead of sitting in a dashboard.
Payment is not a plugin
This is the part that generic website builders get wrong for this market. Stripe is not the answer here. eSewa and Khalti are how people actually pay in Nepal, and integrating them properly, including the failure paths, is unglamorous work that no model writes for you.
If the payment does not clear the way a Nepali customer expects, none of the AI matters. They close the tab.
What we would tell anyone building in this space
- Treat generation as one step in a pipeline, not the product. The pipeline is the product.
- Constrain the model's blast radius. Whatever your equivalent of the dependency graph is, build it early. Retrofitting it is painful.
- Localise the money path first. It is the least interesting problem and the one that decides whether you have a business.
- Assume the connection is bad. Ship less JavaScript than feels comfortable.
The demo takes thirty seconds. The system that makes the demo safe to sell took considerably longer.
Building something like this?
We are a product studio in Kathmandu. Tell us what you are building and an engineer will reply.