What Tech Stack Do AI Builders Produce? A Straight Look

Zugo produces web output: HTML for structure, CSS for the look, JavaScript for behaviour, running in the browser. External capability arrives through connectors rather than being reimplemented, so a database is Supabase and payments are Stripe. The whole project exports to GitHub, and the fastest way to confirm any of this is to read the source yourself.

"What stack" is really three questions wearing one coat: can a developer maintain it, can I host it where I want, and can I leave. This post answers those, and tells you how to verify the answers rather than trusting them.

Why does the stack question matter?

Because it decides who can work on the result. A codebase in a shape developers recognise can be handed to any of them. A codebase in a proprietary format can be handed only to people willing to learn that format first, which is a much smaller group and a much more awkward conversation.

It also decides where the thing can live. Output that a browser opens directly can be served from almost anywhere. Output that requires a specific runtime is tied to hosts that provide it, and that constraint follows you for the life of the project.

And it decides what leaving costs. This is the question underneath the other two. A visual platform where you assemble screens on a canvas is a commitment, because the screens are not files. Text files are portable by nature, which is a property no feature list can replace.

What does Zugo actually output?

A working browser project. The page you publish is markup, styles and script that a browser loads and runs, which is why a build can be opened at <slug>.zugo.run immediately without any provisioning step on your side.

The design layer is CSS, driven by custom properties rather than a component framework, and typography is loaded as an ordinary web font stylesheet. Interactive behaviour is JavaScript in the page: state, storage, and whatever the build was asked to do when a button is pressed.

When you connect Supabase, the generated page loads the Supabase client as an ES module at a pinned version and talks to your project directly from the browser. Pinning matters more than it sounds: code running on your published origin, next to your visitors' data, should not change under you because a third party shipped a release.

How can you check the stack yourself?

By reading it, which takes about a minute and beats any claim in this post.

The third row is the one worth doing before you plan anything around search. If your sections share one address with a fragment after the #, a search engine sees a single page, which is fine for a landing page and limiting for a content site. That is covered further in is an AI-built website good for SEO.

The fourth row is the honest test of every ownership claim any builder makes, including ours. Do the export on a throwaway project before you need it, not on the day you are leaving.

What does that stack make easy?

Four things, and they are the reason the choice was made.

Anyone can read it. Markup, styles and script are the common language of the web. A developer does not need to learn a proprietary abstraction before they can help you, which shortens the first conversation and lowers the quote.

It runs anywhere. A browser project can be served from Zugo's hosting at <slug>.zugo.run, deployed to your own Vercel account through the connector, or served from anywhere you like once the repository is in GitHub.

Nothing sits between you and the result. What you read in the source is what the browser executes. Debugging is looking at the page rather than reasoning about a build pipeline.

The failure surface is small. Fewer moving parts between your description and a rendered page is part of why a simple build lands in about a minute and a multi-page platform takes several.

What does that stack cost you?

Three real trade-offs, and a builder that does not name them is not being straight with you.

It is not a React or Next.js codebase. If your team standardises on a framework, or your hiring plan assumes one, generated output will not match that expectation and you should know before you start rather than after. What you get is portable and readable, not what a framework-shaped team is used to opening.

One document has a ceiling. A project assembled as a single browser document is excellent up to a point and gets unwieldy past it. Very large applications are the shape where a development team and a conventional codebase earn their cost, and Zugo does not replace a development team on a complex product.

No component ecosystem. There is no marketplace of pre-built blocks to install. Anything unusual is generated for you or built up through successive edits. Sometimes that is better than hunting for a plugin. When a mature one already exists, it is not.

Where do the external services fit?

Alongside the page rather than inside it, which is the part that changes how the stack question should be asked.

Read that as a second stack sitting under the first. The generated page is small because the heavy, security-sensitive pieces are handled by services built for them. A generated app never stores a card number, because Stripe does, and it never hashes a password, because Supabase does.

That arrangement is also what a competent developer would have built. The interesting difference is that in a builder these are three clicks rather than three afternoons.

What does it cost to try the stack on your own project?

Per action, published in advance, so the arithmetic happens before you commit.

The Free plan carries 5 credits once, less than one fresh build, so evaluating output on your own idea means a paid plan. Pro is $25 per month with 200 credits, roughly 16 full platforms or 33 quick builds. Business is $99 per month.

For a stack evaluation specifically, one build is enough. Spend 6 credits on something small, publish it, read the source, export it, and open the repository. That sequence tells you more about the output than any documentation, and it is the same sequence a developer you hire will run on day one.

What should you ask any AI builder about its stack?

Four questions, in this order, because each one makes the next one meaningful.

Can I see the source of a published page without asking permission. Can I export it to a repository I control. Does the export contain the whole project or a snapshot of the visible page. And can I run and change it without the builder in the loop.

A tool that answers yes to all four has made the stack question mostly academic, because whatever the answer is, you can go and look. A tool that answers no to the second or third has made it the most important question you will ask, whatever the stack turns out to be.

The related practicalities are in can I export the code and can a developer take over later. If you would rather check than read, describe something small at Zugo, publish it, and view source on the result.