August 9, 2026 · Guide

Your first build, minute by minute

This article describes the product at publication. See AI Builder and Agent Teams for current capabilities.

Mistake one: writing a spec instead of a sentence

People who've been burned by bad software before tend to open the builder and type a paragraph. Grading system, unit preferences, offline mode, color scheme, all front-loaded before the first response even comes back. It feels responsible. It isn't. The builder reads your one sentence, infers what you probably mean, and comes back with a plan in about fifteen seconds — "a training log for climbers" turns into a session log, a grade-tracking view, and a dashboard, with V-scale bouldering and YDS routes picked as the default because that's what most climbers actually use. It tells you what it picked, right there in the plan, so you can correct it in one line if you're the exception. Writing the paragraph up front doesn't skip that step. You still get a plan, you still have to read it, and now you've spent three minutes typing constraints that the plan would've surfaced for you anyway, in the order that actually matters for your build.

The plan isn't a form with blanks to fill in. It's prose, and you answer in prose. "Actually make it Font grades, I'm in Europe" is a complete edit. So is "add a partner/belay-log field, I climb with different people." Each edit regenerates the plan, not the build — you're steering before the expensive part starts, not restarting it. Approving that plan is the last decision you're required to make. Everything after is generation and verification.

Mistake two: watching the feed like a stalled terminal

The build runs server-side, and the wreckage here is almost always a false alarm: someone stares at a quiet activity feed for two minutes and assumes it's hung. It isn't — it's in a phase that doesn't produce visible output every second, and the feed labels which phase you're in for exactly this reason. You can close the tab entirely. The run doesn't live in your browser.

What you should actually expect varies a lot by shape. The climbing log — a few pages, a local data model, nothing calling out to an external API — lands in under three minutes, which is typical for anything that's basically "log this, chart that, show me a list." The moment a build needs a real backend, auth, a database with relationships, background jobs, you're looking at eight to twelve minutes, because now there's schema generation and migration, and the verification pass runs a second time against server code instead of just markup. Games are slower still, because they need asset generation: sprites, sound cues, sometimes a second visual pass if the first attempt doesn't read right at the size it's meant to be shown. And native packaging, an actual installable APK, not a web view wrapped in a shell, hands off to a real toolchain. Gradle, signing, all of it. That step alone can add five to ten minutes on top of everything else, and it's the one phase where a quiet feed means the toolchain is doing toolchain things, not that anything broke.

The honest cost of this model is that you lose the instant, character-by-character feedback of watching code stream into an editor. What replaces it is a system that survives your laptop sleeping and your wifi dropping, that you can check from your phone, that keeps running whether or not you're the one watching it. For a ninety-second build that trade barely registers. For the twelve-minute backend build, it's the difference between babysitting a terminal and getting coffee.

Mistake three: confusing generated with done

This is the expensive one. A build that finishes fast and hasn't been checked is not a finished build, it's a draft that happens to run — and the gap between those two is where most fast site-builders get their bad reputation, shipping forms with no sanitization and buttons nothing can reach by keyboard. Before this platform calls anything done, separate verifier agents review it: code, security, links, SEO, accessibility, and conformance against the plan you approved. That's a genuinely separate pass, not the same agent rereading its own output and nodding.

The security check hunts for the boring stuff that actually bites people in production: an API key committed into client-side code, a form accepting input with no sanitization, an endpoint trusting a client-supplied user ID instead of deriving it from the session. The accessibility check isn't a linter you can silence with a comment — it's checking real contrast ratios and whether interactive elements are reachable by keyboard.

Conformance is the one people underrate most. It's easy for a generation pass to quietly drop something you asked for — that partner/belay-log field from your plan edit, say — three files into the build, deprioritized without anyone deciding to drop it. Conformance rereads your approved plan against the actual output and catches the gap. When it finds one, the fix gets applied and rechecked automatically; you don't get a to-do list, you get either a fix you never see or nothing wrong to begin with. The mechanics of what each verifier checks, and what happens when something fails twice in a row, are in How builds verify themselves. The one thing worth carrying out of this section: done means passed, not generated. Treat those as the same claim and you'll eventually ship the exposed key or the unreachable button.

What you get if you skip all three mistakes

  • A working product in a real preview you can click through — an actual running instance with your data wired up, not a screenshot of what it'll look like.
  • A chat thread attached to it, where "make the header darker and add a stats page" produces version two next to version one. The old version doesn't vanish; it sits there as a fallback while the new one takes the live preview.
  • Buttons that do things: publish live, download the code, build native installers, ship to a store. Not upsell modals dressed as buttons.

That download-the-code button is worth a second look, because it's what separates a tool you'd trust with something real from one you'd only use for throwaway prototypes. If the code is genuinely yours to take, readable file structure, no exotic lock-in beyond what you actually asked for, then the platform has to keep earning your next session instead of coasting on the fact that you're already stuck inside it.

The habit worth forming: iterate in the chat, not in your head. Don't draft a mental list of five changes before you say anything — say the first one, look at version two, then decide if the other four still matter. Half the time they don't, because seeing the real thing changes what you actually wanted next.
Guide
ShareXLinkedInFacebookRedditQuoraWhatsAppTelegramEmail
← All posts