App Builder: From a Prompt to a Working App You Can Watch Run

Most prompt-to-app tools hand you a project. A folder tree, a package manifest, a dev server to start, a build step that has to succeed before you can see anything. That is the right shape when you are starting a product. It is the wrong shape when you want to answer a smaller question: what would this thing feel like if it existed?

App Builder is built for that smaller question. You describe an app in plain language, and it returns one self-contained HTML file that renders immediately in a live, sandboxed preview. There is no folder to open, no server to run, no build to wait on. You watch the app run, you talk to it to change it, and when it is ready you share it with a link or download the file. This post is about what that single-file constraint actually buys, how the revision loop works, where the limits are, and what it costs.

What "single-file" actually buys you

The core decision is that every app is exactly one HTML document, with its markup, styles, and scripts all inline. That one decision is what makes everything else work.

No build step. The file is complete the moment it is generated. There is nothing to compile, bundle, or install. That is why the preview appears the instant the model finishes writing, instead of after a toolchain has run.

It runs in a sandboxed iframe. The generated document renders inside an iframe using the srcdoc attribute with a restrictive sandbox policy that permits scripts but nothing else. It cannot navigate your page, reach for your cookies, or pop out of its frame. You interact with the real running app, not a screenshot, and it stays walled off from the surface it renders on.

It is a downloadable artifact. Because the app is one file with no external local dependencies, "download" means exactly what it should: you get a single .html you can open by double-clicking, host on any static bucket, email to someone, or drop into another project. Nothing is locked inside the builder. There is a Copy HTML button too, if you would rather paste it somewhere directly.

It is a shareable link. Publish a build and it gets a public, read-only preview URL that anyone can open without signing in. That makes it a fast way to put a working thing in front of a teammate or a client without deploying anything.

To make a single file behave like a real app, the builder standardizes on a small, pinned stack loaded from CDNs: Tailwind via the Play CDN for styling, and React 19 pulled from esm.sh with Babel Standalone transpiling the JSX in the browser. Every dependency is pinned to an explicit version rather than latest, so an app you generate today does not silently break the day a CDN ships a major version. Simple, mostly-static pages get plain HTML and Tailwind instead, so a trivial app does not carry a React runtime it never uses.

How revisions work: you talk to the app

The first message builds the app. Every message after that revises the same app in place.

The interface is a split view: a chat rail on one side, the live preview on the other (they stack on mobile, with the preview on top). You send "make the header sticky" or "add a dark mode toggle" or "the total is not updating when I change quantity," and the builder regenerates the complete document with your change applied and re-renders it. You are not accumulating diffs against a repo or resolving merge conflicts. You are describing the app you want and watching the current version become it.

Under the hood, a revision is not a fresh start. The builder passes the current HTML plus recent conversation turns back to the model with your new instruction, and asks for the full updated document. That is why "make it blue instead" understands what "it" is, and why a fix to one thing does not quietly undo the last three changes you asked for. The preview refreshes on every build so you always see the live result, and each app you make is saved, so you can reopen an earlier build and keep iterating on it later.

This is the same organizing idea behind the rest of the platform: capability metered by a single credit balance, results that persist as real artifacts rather than throwaway output. If you want the architectural version of that argument, it is laid out in One Endpoint, Every Capability.

The honest limits

Single-file is a real constraint, not a marketing angle, and it is worth being precise about what it rules out.

It is one file, not a project scaffold. App Builder does not produce a Next.js repo, a package.json, a route tree, or a folder you open in your editor and grow into a product. If your end state is a full application with a backend, a database, and a deploy pipeline, this is the wrong tool for that step, and it is not trying to be. It is for the step before that, when you want the working shape of the idea in your hands fast.

Dependencies are CDN-pinned, not bundled. The React and Tailwind runtimes load from esm.sh and the Tailwind Play CDN at view time. That is what removes the build step, and it also means a generated app needs a network connection to render its dependencies, and its capabilities are bounded by what those pinned CDN libraries provide. It is the right trade for a live preview and a portable file; it is not how you would ship a production bundle.

No secret-bearing API calls. Because the app is a public, shareable, downloadable file, it does not call external APIs that need keys, and it should not. When an app needs data, it generates realistic sample data inline, and it can persist state to localStorage. That keeps every build safe to share by default. It also means App Builder is at its best for tools, calculators, dashboards, widgets, interactive pages, prototypes, and demos, rather than anything that has to talk to your private backend.

Knowing where the edges are is what makes the tool useful. Reach for it when you want a working artifact now; reach for a full scaffold when you are committing to a product.

What it costs

App Builder runs on the universal Developers Digest credit balance, the same credits that power chat, image generation, and everything else in the suite. There is no separate subscription for it.

The first build of an app costs 20 credits. Each revision costs 5, because a revision reuses the prior app as context and is cheaper to produce than a fresh one. The cost is shown in the composer before you send, so you always know what a build will run before you commit to it. New accounts start with 25 free credits, which is enough for one full build plus a revision to see the loop end to end before paying for anything.

Try it

The fastest way to understand App Builder is to build something small and then change it twice. Describe a pomodoro timer or a sortable table of sample data, watch it render, then tell it to restyle the header and add one feature. Two revisions in, the loop clicks: plain language in, a working app out, and a file you can take anywhere.

Start at App Builder, or read the pricing if you want the credit math first.

FAQ

What is App Builder?

App Builder turns a plain-language prompt into a working single-file app with a live, sandboxed preview. You describe what you want, see it run immediately, refine it by talking to it in chat, and then share it with a link or download the file.

What kind of apps can I build?

Self-contained single-file apps: tools, calculators, dashboards, widgets, small interactive pages, prototypes, and demos. Because each app is one HTML file with no build step, it stays easy to preview, share, and download. It is not built to scaffold a full multi-file product with a backend.

How do revisions work?

Every message after the first one revises the same app in place. The builder passes the current HTML and recent conversation back to the model with your new instruction and returns the complete updated document, then re-renders the preview. So "make it blue" or "fix the total" applies to the app you already have, without starting over.

Can I take the app with me?

Yes. Every app is a single self-contained file. Download the .html and open it by double-clicking, host it on any static bucket, or drop it into another project. You can also copy the raw HTML, or publish a public read-only preview link. Nothing is locked inside the builder.

Is the preview safe?

The app renders inside an iframe with a restrictive sandbox policy that allows scripts but blocks navigation, popups, and access to the surrounding page. Generated apps also avoid API calls that need keys, so a build is safe to share by default.

How much does it cost?

The first build costs 20 credits and each revision costs 5, on the universal Developers Digest credit balance shared across every app. The cost is shown before you send. New accounts get 25 free credits, enough for a full build plus a revision. See pricing for the details.