What non-technical vibe coders are building
Non-technical vibe coders build three things: demos to prove an idea works, deliveries a client owns and pays for, and products meant to become businesses.
Last updated
Non-technical vibe coders build three things: demos to prove an idea works, deliveries a client owns and pays for, and products meant to become businesses. The interesting part is not the code they write, since they write none, but how early the build type decides whether the thing gets payments, persistence, or a real database at all.
What kinds of apps do non-technical people actually ship?
On this platform, what gets built falls into three categories chosen before the first line of source is written. A demo has no payments, memory only, and one QA pass. It exists to show something works. A delivery has a real database, payments wired to a client's own account, and up to four QA iterations until a separate agent verifies it does what was asked. A product is a business of its own: real database, payments provisioned automatically, up to five QA iterations. The distinction matters because a demo that later needs to take money is not upgraded in place. It is rebuilt as the type it should have been, because payments and persistence reach into every part of the app. Somebody who vibes a demo and then asks to bolt on Stripe discovers the whole shape changes.
The build flow is the same regardless of type. You describe the app in chat in plain language, not a spec and not a form. The platform returns an editable capability blueprint, which is a list of what it thinks you asked for. You change, remove, or add capabilities there. A manager agent turns the blueprint into a build plan, a builder agent writes real source into a repository, and the app deploys itself to a K3s cluster as a Helm release. A QA agent opens the deployed app in a real browser and checks it against the blueprint. A build that does not pass does not get called done. If you want to understand why that last step matters, /learn/why-one-shotting-your-whole-ai-app-is-the-fragile-part covers what breaks when you skip it.
What gets rejected before it gets built?
Not everything someone describes in chat makes it to a build. Two products were stopped at the research gate recently, and the reasons are more useful than any success story because they show where vibe coding hits a wall that is not technical.
The first was a tool for independent UK and Ireland plant hire firms that would automatically track machine on-hire and off-hire. The research found general equipment-rental pain, mostly from US dumpster and generator businesses, but no concentrated demand signal from UK and Ireland plant hire firms specifically. There was no evidence that incumbents like Rentman, HireHop, or CapjaDesk leave a credible gap. The idea sounded specific but the market was not there in the shape described.
The second was a tool to consolidate the fragmented admin stack German dog groomers run, replacing WhatsApp for booking conversations and scattered spreadsheets. The research itself concluded the product idea was essentially Mimos, a German-market grooming tool that already ships WhatsApp reminders, deposits, breed data, calendar, and cancellation policies to the exact same customers. There was no credible wedge. In both cases the platform said no before building, which is the cheaper failure. A demo built on a non-market costs tokens and time. A rejection costs a paragraph.
What happens when a vibe-coded app needs to take real money?
Payments are where the demo-to-product jump catches people. A demo has memory only and no payment wiring. The moment you need to charge a card, the app needs a real database, a payment provider provisioned, and persistence that survives a restart. On this platform that means choosing delivery or product as the build type from the start, or accepting a rebuild. A delivery wires payments to a client's own account. A product provisions payments automatically as part of the build. Both get a real Postgres database deployed alongside the Helm release. The database is pinned to its major version, and a major upgrade is a deliberate migration, never a tag change. That rule exists because a real incident here: an image tag moved from Postgres 15 to 16, Postgres refused to upgrade its data directory on start, and the container crash-looped forever. That failure mode is now impossible by construction.
If your question is really about whether you can build something that takes money without writing code, the answer is yes, but only if you pick the right build type before you start. /learn/what-does-production-ready-actually-mean-for-non-coding-founders goes deeper on what production-ready means when you are not the one reading the logs.
Where does the app actually live once it is built?
This is the part that separates a vibe-coded app that survives from one that vanishes. Most AI app builders host the app for you. When you leave, you start again. Here, every app lands in a Kubernetes cluster you own, deployed as a Helm release in a namespace that belongs to your account, on K3s. You can join your own hardware to the cluster over a private network, and pods schedule onto it like any other node. A machine at home becomes a node, and the running cost of the app approaches zero. The source is a real repository, not a proprietary format or a visual builder export. It is an application you could run anywhere Docker runs.
The deploy itself is a push to the repository. The pipeline compares paths against the previous commit, rebuilds only the services that changed, and rolls them out with helm upgrade --atomic, which is a zero-downtime rolling update on K3s. A release that fails its health checks rolls back rather than half-landing. Nothing about the runtime is invented here. Kubernetes, Helm, Postgres, Docker. Somebody who knows those knows this. If you want a landing page and never want to see infrastructure again, a hosted builder is a better fit, and this will feel like more machinery than the job needs. /learn/why-are-people-churning-from-ai-app-builders covers why people leave the hosted ones.
On this platform, what a non-technical person builds is the same thing a technical person builds: a real application in a real repository on a cluster they own, verified by an agent in a real browser before it is called done. The difference is they described it in a chat window and never touched the source.