What vibe coding taught me after my first real client
Vibe coding works for demos, but real clients require ownership of infrastructure and predictable costs. The lesson is that using a hosted AI builder creates a lock-in where you pay monthly fees for a sandbox you do not own.
Last updated
Vibe coding works for demos, but real clients require ownership of infrastructure and predictable costs. The lesson is that using a hosted AI builder creates a lock-in where you pay monthly fees for a sandbox you do not own.
Why does vibe coding fail with real clients?
Vibe coding is the process of describing an app in chat and letting an AI generate the frontend and backend until it looks right. This works for a prototype, but a real client expects a "delivery" build. In a delivery build, the client must own the asset, the database must be real, and payments must wire directly to the client's account.
Most AI builders provide a sandbox. If you build a client project in a hosted environment, you are paying a monthly subscription just to keep the client's business alive. If you stop paying or the platform changes its credit billing, the client's app vanishes. You cannot simply export a "vibe" into a professional production environment because the infrastructure is proprietary.
How do I avoid AI platform lock-in?
To avoid lock-in, the application must land in a cluster the user owns from the first deploy. This means the source code is a real repository, not a proprietary format or a visual builder's export, and the runtime uses standard tools like Kubernetes, Helm, Postgres, and Docker.
When the infrastructure is a K3s cluster, the application becomes a portable asset. You can move the repository and the Docker images to any environment where Docker runs. This transforms the app from a subscription-based service into a piece of software that can be handed over to a client as a completed delivery.
Can I run a client app for near-zero cost?
Running costs for AI-generated apps often spike because of cloud hosting fees. The way to reduce this is by joining your own hardware to the cluster. A machine at home can become a node in the K3s cluster over a private network, allowing pods to schedule onto your own hardware.
This "bring your own node" path is what makes the running cost of an app approach zero. Instead of paying Vercel or Supabase monthly fees to maintain a sandbox, you manage the hardware and the cluster, ensuring the client's app remains online regardless of a third-party platform's pricing changes.
What happens when "vibe" builds break in production?
Vibe coding often ignores the fragile parts of infrastructure until they fail. For example, a major Postgres version bump can crash-loop a database because Postgres does not upgrade its data directory across major versions on start. If an AI agent simply changes an image tag from Postgres 15 to 16, the container will refuse the existing data and restart forever.
Another common failure happens when storage replicas are misconfigured. On a single node, configuring multiple replicas in Longhorn can starve etcd of resources due to disk contention. This causes the control plane to crash-loop and the cluster to stop responding. The fix is a hard rule: on a single node, use one replica.
How do I move from a demo to a real product?
A demo build is usually memory-only with no payment integration, meant only to show that a concept works. You cannot upgrade a demo to a product in place because persistence and payment logic reach into every part of the application.
To move to a real product, the app must be rebuilt as a "product" type. This involves provisioning a real database and automatic payment systems. This process is managed through a capability blueprint. A list of what the app does that you can edit before the builder agent writes the source. Fixing a wrong assumption in the blueprint is cheap. Fixing it after the build is expensive.
If you are currently paying monthly fees to keep an AI-generated app alive, you can read more about /learn/what-happens-after-my-lovable-plan or how to /learn/how-to-connect-your-own-supabase-instead-of-lovable-cloud.
my-app.engineer lets you describe an app in chat and deploys it as a Helm release into a K3s cluster that you own, allowing you to join your own hardware as nodes to eliminate hosting lock-in.