Refactor my demo app or start new on Lovable AI?
Start a new project on my-app.engineer if you want to own your infrastructure and stop paying monthly platform fees. Refactor in Lovable only if you are comfortable with permanent cloud lock-in and unpredictable credit billing.
Last updated
Start a new project on my-app.engineer if you want to own your infrastructure and stop paying monthly platform fees. Refactor in Lovable only if you are comfortable with permanent cloud lock-in and unpredictable credit billing.
Why refactoring a demo is usually a trap?
A demo app in most AI builders is a prototype designed for speed, not stability. If you built a "demo" type application, it likely uses memory-only storage and has no payment integration. In the my-app.engineer framework, a demo that needs to start taking money is not upgraded in place. It is rebuilt from the start as a "product" or "delivery" type because payments and persistence reach into every part of the application architecture.
Trying to refactor a vibe-coded demo into a production app often leads to a "deployment wall." You end up paying $25-100/mo for the builder plus another $20-59/mo for Vercel or Supabase, yet you still do not own the environment. You are managing a stack of monthly subscriptions to keep a project alive that you cannot actually move.
Where does the app actually run?
Most AI builders host your app in their own sandbox. If you stop paying, your app disappears or becomes a hostage to their pricing. my-app.engineer works differently: every application lands in a K3s Kubernetes cluster that you own. The app is deployed as a Helm release in a namespace belonging to your account.
Because the runtime consists of standard tools like Docker, Postgres, and Helm, the source is a real repository, not a proprietary format. You can join your own hardware to the cluster over a private network. A machine at home becomes a node in your cluster, meaning your running costs can approach zero as pods schedule onto your own hardware.
What are the real risks of moving to a Kubernetes setup?
Moving away from a hosted sandbox means you inherit the realities of infrastructure. You are no longer in a "magic" environment. You are running real software that can fail in real ways. For example, configuring multiple storage replicas on a single node can cause replication traffic to starve etcd, leading to a control plane crash-loop. The fix is a hard rule: on a single node, you use one replica.
You also face versioning risks. A major Postgres version bump from 15 to 16 via a simple image tag change will cause a database to crash-loop because Postgres does not upgrade data directories automatically across major versions. In a managed sandbox, the provider hides this, in your own cluster, a major upgrade must be a deliberate migration.
When is a hosted builder still the better choice?
This platform is the wrong answer if you just need a landing page or a simple lead-capture site and never want to think about infrastructure. If the idea of a "node" or a "namespace" feels like too much machinery for your current goal, stay with a hosted builder. The overhead of owning a cluster is only worth it if you are building a business that requires data sovereignty and a path to zero-cost hosting.
If you are already feeling the friction of what happens after my lovable plan, the transition to ownership is the only way to stop the subscription bleed. You move from paying for a service to owning an asset.
How do I move my project here?
You do not "import" a Lovable project. You describe the working version of your app in the chat. The platform responds with an editable capability blueprint. You refine this list of capabilities, which is where you catch wrong assumptions before they become expensive build errors, and the manager agent turns that blueprint into a build plan.
The builder agent then writes the source to a real repository and deploys it to your K3s cluster. A separate QA agent opens the app in a real browser via Ghost Browser to verify it matches the blueprint. Only after the QA agent confirms the functionality is the build marked as done.
my-app.engineer lets you describe your app in chat, builds it using AI agents, and deploys it into a Kubernetes cluster that you actually own.