AI App Builder With OpenAI: Adding AI Inside Your App
AI App Builder With OpenAI: Adding AI Inside Your App
Two different things get called the same name. One is the AI that builds your project from a description. The other is an AI feature living inside the finished product, answering your users while they use it. Zugo does both, but through different routes, and the second one is where the confusion sits.
The short version: you do not need to bring a model provider account to put an AI feature in a generated app, and if you specifically want OpenAI rather than what ships built in, the path runs through a code export rather than through a connector.
Is there an OpenAI connector in the integrations list?
No, and it is better to say that plainly than to let you find out after signing up. The built-in integrations are Supabase for database, login and files, Stripe for payments and subscriptions, GitHub for source export, Vercel for deploying to your own account, Resend for email, your own domain, and Google Analytics. A model provider is not one of them.
What exists instead is an AI runtime inside every published project, reachable from the project's own code as window.zugoAI. Your app sends a prompt while a visitor is using it and gets the answer back. There is no key in your client code, because the call travels through the platform rather than straight to a provider.
That design choice solves a real problem rather than a marketing one. A browser app cannot hold a provider key safely, so the ordinary way to add a chat feature to a small web app is to stand up a server that holds the key and proxies the request. That server is usually more work than the feature it exists to serve.
The details of the runtime, including its modes and how calls are metered, are covered in Zugo AI. This article is about the decision sitting above it: built in, or your own provider.
What does an AI feature inside a generated app look like?
Four patterns cover most of what people actually ask for, and all four fit inside one build prompt.
A support answer box on a landing page. The visitor types a question in their own words and gets a reply constrained to the information you supplied. Different from an FAQ, which only answers the questions you thought of in advance.
A text tool where the output is the product. Paste a rough email, get a polished one. Paste notes, get a summary. Here the model is not a helper beside the app, it is the app.
Dialogue in a browser game. A character that responds to whatever the player types, instead of reading from a fixed table of lines. One sentence of personality description does more work than a page of authored dialogue.
A hint or explanation button. A quiz that generates a nudge for the exact state the player is stuck in, or a dashboard that explains a chart in plain words on request.
How do you describe an AI feature in the prompt?
Name three things and the result lands close on the first attempt: what triggers the call, what the model should behave like, and what shape the answer takes.
A weak prompt says "add AI". A strong one says "add a help box on the pricing page: the visitor types a question, the assistant answers only from the plan descriptions above, two sentences maximum, and says it does not know rather than guessing."
The last clause is the one people leave out and then regret. A model with no instruction about its own limits will confidently answer things it has no basis for, and on a page that quotes prices or terms, that is not a quirk, it is a liability.
Everything after the first build is an edit. Making the assistant stricter, shorter, warmer or more cautious is a sentence in the chat, and each edit rebuilds and re-verifies the project in the sandbox before you see it.
Built-in runtime or your own OpenAI key: which do you need?
| Built-in AI runtime | Your own provider key | |
|---|---|---|
| Setup | None, it ships with the project | Export the code, add the key, host it yourself |
| Where the key lives | Not in your code at all | In your environment variables, your responsibility |
| Choice of model | The modes the platform offers | Any provider and model you want |
| Billing | Inside your Zugo credits | A separate account and a separate bill |
| Editing by chat | Yes, keeps working | No, you are editing code by hand from then on |
| Best for | Getting a feature live and testing whether anyone uses it | A specific model, a fine-tune, or an existing provider contract |
The honest reading of that table: the built-in route wins on time to a working feature, and the export route wins on control. Most projects need the first one for the first month and only some of them ever need the second.
If you do go the export route, the mechanics are ordinary. Source code goes to your GitHub repository, you add the provider call and the key where it belongs, and you deploy from there. The GitHub integration covers what lands in the repository, and deploying to Vercel covers serving it from your own account afterwards.
What does an AI feature cost to build?
The generation is priced like any other work. A build costs 6 credits, an edit costs 3, and a multi-page platform costs 12 for the first three pages plus 3 for each page beyond them. Hi-Fi mode doubles both, so a build is 12 and an edit is 6.
Free includes 5 credits, Pro is $25 per month for 200 credits, and Business is $99 per month for 800. Two hundred credits works out to roughly 16 platforms, 33 builds or 66 edits, counting one kind of action at a time.
Two things follow from those numbers. Free credits are enough to see the interface and get a feel for the loop, but one build already costs more than the free grant, so treat it as a trial rather than a launch budget. And an AI feature is usually not a separate project: it is one extra sentence in a prompt you were writing anyway, so it costs an edit, not a rebuild.
The running cost is the part worth thinking about longer. Calls made by visitors to a published app draw on your balance, not theirs. A quiet internal tool barely registers. A public page with a chat box that anyone can hold a conversation with is a different shape of spending, and it is worth capping the length of replies before you find that out from your balance.
What breaks when the model sits inside a live product?
Four things, and none of them are exotic.
Latency is real. A call takes as long as the model takes, and a button with no loading state reads as a broken button. Ask for a typing indicator in the same breath as the feature itself.
Verification checks the build, not the answers. Every project is booted in a sandbox before it is handed over, and one that fails to open is reported rather than delivered. That is a check on whether the page runs. Whether your assistant answers well lives entirely in your instructions, and a vague instruction produces a vague assistant.
Model output is not deterministic. The same question can come back phrased differently on two attempts. For a support box that is fine. For anything where a specific number or a legal sentence must appear verbatim, put that text on the page yourself and let the model point at it.
And the honest boundary: a builder does not replace a development team on a complex product. An AI feature that has to read a private database, respect per-customer permissions and log every exchange for audit is a real engineering task, not a prompt. Doing the first version here and handing over the hard version later is a reasonable plan; expecting the hard version from one description is not. What an AI builder cannot build draws that line in more detail.
What should you build first?
Something small enough that you will actually use it this week. An answer box on a page you already have, or a rewriting tool for a piece of text you produce repeatedly. Both are one prompt plus one or two edits.
Then watch how people use it before you make it cleverer. The gap between what you expected visitors to type and what they actually type is the most useful thing an AI feature teaches you, and it arrives in the first day.
You can build and publish the whole thing, from description to a live address, at zugo.dev. If it turns out you need a specific provider after all, the code is yours to take, and that exit stays open whether you use it or not.