How Long Does It Take to Build With AI? Honest Numbers

About a minute for a simple build and a few minutes for a multi-page platform. That is generation time on Zugo, not project time. The honest figure for a finished, published site is closer to an evening, because the first draft is a starting point and the edits are where the hours go.

Most answers quote the first number and stop, which is why people arrive expecting a finished website in a minute and feel misled by hour three. The useful answer separates the four different clocks that all get called "how long it takes".

How long does the actual build take?

A single-page site, app, or game comes back in about a minute. A multi-page platform with several linked screens takes a few minutes, because there is more to generate and more to verify before anything is handed to you.

Those numbers cover generation plus a check. Every build is booted in a sandbox first, and a build that fails to open is reported as a failure instead of arriving as a blank screen. That check costs seconds and lowers the risk of a dead publish, though it does not confirm your copy is correct.

What the clock does not include is your reading time. A minute produces a draft. Deciding whether that draft is any good takes as long as it takes to open it properly on a phone and on a laptop, which is never zero.

Nor does it include the time before the prompt. Writing down what the site is for, who it addresses, and what a visitor should do takes ten quiet minutes and shortens everything after it. Skipping that step does not save time, it moves the time into the edit loop.

What is on the clock besides generation?

Four stages, and only the first one appears in most marketing copy. The other three are yours, and they are where a realistic schedule comes from.

The third row decides your evening. An edit costs 3 credits and returns quickly, so the constraint is not the machine, it is how fast you can look at a screen and say precisely what is wrong with it.

The fourth row surprises people. Connecting a custom domain involves a DNS record that propagates on somebody else's schedule, and no builder controls that clock.

How long does each type of project take?

Different outputs have genuinely different shapes, and lumping them together is how expectations break.

A landing page is the fastest honest case: one build, three or four edits for copy and images, published the same hour. A portfolio takes longer only because you spend time choosing and cropping photographs, not because generation is slower.

A multi-page platform with a database and login is a different category. Generation takes a few minutes, but the first working version usually needs several rounds: the data model is where the misunderstandings live, and each one surfaces only when you click through the screens. Read what a multi-page build involves before you budget an afternoon for one.

A 2D browser game is playable in a minute and tunable for an hour, because the fun is in numbers you cannot judge until you play: jump height, spawn rate, difficulty curve. That hour is the enjoyable part, but it is still an hour.

Why do edits set your real timeline?

Because the first draft answers the prompt you wrote, not the product you imagined. The gap between those two is the entire project, and it closes one edit at a time.

A vague prompt produces a draft that is 60 percent right and needs ten edits. A specific prompt naming the pages, the audience, and the one action you want visitors to take produces a draft that is 85 percent right and needs three. The prompt is where you buy back time, and it is free to write carefully.

Edits are also where very specific business logic gets built. Unusual permission rules, approval steps, and anything with awkward edge cases arrive through iteration rather than in a single description. That is not a defect in the tool, it is how the tool is meant to be used, but it does mean an unusual product takes longer than a conventional one.

What makes a build slower than it should be?

Four causes, all avoidable, and all of them are about the prompt rather than the platform.

Describing a business instead of a structure. "A website for my law firm" leaves every decision to inference. Naming four pages and their contents cuts the edit count roughly in half.

Asking for everything at once. A first prompt with fifteen features produces fifteen half-right features. Build the core, publish it, add the rest against real feedback.

Untouched camera images. Six-megabyte photographs make a page slow and make you spend time debugging something that is not a build problem.

Changing your mind about the data model. Renaming what a record is halfway through a platform touches every screen that reads it. Decide the nouns before the first build.

None of these are exotic. Three of the four are decisions you can make in a notebook before you open the builder at all, which is why the fastest projects tend to belong to people who spent the first ten minutes writing instead of generating.

How long before the site is actually live?

Publishing itself is immediate. A published project gets an address at your-project.zugo.run the moment you publish it, and that link works for anyone you send it to.

A custom domain adds the DNS wait. You point a record at the project, then wait for the internet to agree, which is usually minutes and occasionally hours depending on your registrar. Nothing about that is specific to AI builders, and connecting a domain is worth doing before you start sharing links rather than after.

Connectors add their own small setup. Supabase for the database and login, Stripe for payments, Resend for email, Google Analytics for traffic, Vercel if you want it deployed to your own account, GitHub if you want the source. Each is a short configuration step, not a build, but budget fifteen minutes apiece the first time you do one.

The sequence that wastes least time is to publish on the free address first, check the site on a real phone, and only then attach a domain and connectors. Reversing that order means debugging DNS and email at the same moment you are still deciding what the page should say.

When is "a few minutes" the wrong expectation?

When the project is not really a website. Three honest cases where the timeline stops being measured in minutes at all.

A complex product with a team behind it. Zugo does not replace a development team on a real application. It gets you to a working, published version far faster than hand-coding, and past a certain complexity the sensible move is to export the source to GitHub and hand a normal repository to a developer.

A migration with history. Moving an existing site with hundreds of URLs and redirects is a data project first. The new build takes minutes; the redirect map takes days, and no builder shortens it.

Anything with real content debt. If the copy is not written and the photographs are not taken, the build is not the bottleneck. This is the most common reason a "one evening" project becomes a two-week one, and it has nothing to do with generation speed.

Where the minute-scale answer does hold is the common case: one person, a clear idea, a site or small app that should look designed on purpose. Whenever you read a build-time figure, check what it is measuring: one generated page and a full multi-page platform are different jobs, and the gap between them is worth knowing before you plan around either. If you want the cost side of the same question, see what an AI-built website costs.

The practical plan: write a specific prompt, expect a draft in about a minute, and reserve the evening for the edits that turn a draft into something you would send to a customer. You can time it yourself with the free credits at zugo.dev.