What happens to AI mockups in your work?
On this platform, a mockup is a "demo" build type: it deploys to your own K3s cluster, runs in memory only, has no payments, gets one QA pass, and is done when deployed.
Last updated
On this platform, a mockup is a "demo" build type: it deploys to your own K3s cluster, runs in memory only, has no payments, gets one QA pass, and is done when deployed. When a demo needs to become a real product with a database and payments, it is rebuilt as the correct build type, not upgraded in place, because persistence and payment wiring reach into every part of the app.
This matters because it is the exact wall people hit in Lovable and Bolt. You vibe-code a working demo, it looks great, you show it to somebody, they say "can it take payments" or "can users save their work" and the answer from the tool is either no or a painful retrofit. The demo type here is honest about what it is: a thing to show something works, not a thing to run a business on.
What does a demo build actually give you?
You describe an application in chat. The platform returns an editable capability blueprint before anything is built, so a wrong assumption is caught while it is still cheap. A manager agent plans the build, a builder agent writes real source into a real repository, and the app deploys to K3s as a Helm release.
A demo lands at <app>.<user>.my-app.engineer and answers there. A separate QA agent opens the deployed app in a real browser and checks it does what the blueprint said. A build that does not pass QA does not get called done. The difference between a demo and the other build types is decided before the first line is written: demo means memory only, no payments, one QA pass.
The source is a real repository, not a proprietary format. If you wanted to take the demo and run it somewhere else, you could. It is an application that runs anywhere Docker runs.
Why can't you just upgrade a demo to take payments?
Because payments and persistence are not a feature you bolt on. They reach into the data model, the routing, the authentication, the database schema, and the way the build is verified. A demo has none of that scaffolding, and adding it after the fact means rewriting the parts that were written without it.
The platform's rule is explicit: a demo that later needs to take money is rebuilt as the type it should have been. There are two other build types. A "delivery" build means the client owns it, has a real database, payments wired to the client's own account, and QA up to four iterations. A "product" build is a business of its own: real database, payments provisioned automatically, QA up to five iterations.
This is less convenient than a magic upgrade button, but it is the honest answer. The demo proved the idea works. The real build is where the idea becomes something that can take money and keep data.
What happens to the demo after you rebuild?
Nothing forces you to tear it down. It keeps running in your cluster at its address, in memory, doing what it did. You now have two applications on your account: the demo and the real one. The demo is still useful for showing the concept without the weight of a database and a payment flow behind it.
When you are done with it, it is a Helm release in a namespace you own, and you remove it the way you would remove any release from a cluster you control.
Where does the mockup actually run?
It runs on K3s, in a namespace that belongs to your account, deployed as a Helm release. Not in a sandbox owned by the platform. You can join your own hardware to the cluster over a private network and pods schedule onto it like any other node, which is what makes the running cost of an app approach zero.
If you built a demo in Lovable or Bolt and want to understand why that path gets expensive and hard to leave, see /learn/what-happens-after-my-lovable-plan. If you want the full walk from an empty screen to a running app, see /learn/how-do-you-build-an-app-with-ai-agents.
On this platform, a mockup is a real deployment in a cluster you own, not a preview in somebody else's cloud. The demo type is deliberately limited so the gap between "it works" and "it takes money" is a rebuild, not a trap.