Build & Ship: It Works on Your Screen. That's Not the Same as Ready.
AI can build a working application from a description, and a lot of them are genuinely good. What AI does not do is ask the questions nobody asked it: who is allowed to see this record, what happens when the payment succeeds but the page never loads, which key ended up in the repository, and whether the thing you demoed to a customer can survive that customer's second user. This section is about the gap between working and ready.
TL;DR
- The gap is not code quality. It is unasked questions: access, money, data, and what happens when something fails halfway.
- A demo proves it can work. It does not prove it cannot break, and those are different claims.
- The expensive failures are quiet: a logged-in user seeing someone else's record, a charge with nothing delivered, a key sitting in git history.
- Bottom line: the builder did what it was asked. The gap is the question nobody thought to ask.
The uncomfortable part
Here is the moment that catches people. Someone asks a fair question about the app you built: "can a customer see another customer's data?" And you realize you do not actually know. Not because you were careless. Because you never opened that particular door, and the tool that built it never mentioned there was a door.
That feeling is not a verdict on you. Building software by describing it is a genuine skill and it produces genuinely working products. But it changes where the risk sits: from can I make this to do I know what I made. And the second question does not answer itself, no matter how well the first one went.
What's inside this section
Ship Your App is the readiness half, written for people who built something real without a traditional engineering background: client versus server checks, row-level security, the money path from checkout to fulfillment, logged-in versus allowed, keys and rotation, test mode versus live, data model sanity, knowing what personal data you now hold, accepting or reverting an AI change, and being able to explain your own app to someone who asks.
Agents & AI Engineering is the deeper half: multi-agent orchestration, prompt evaluation and regression testing, token economics, code review discipline, prompt injection, and agent security. This is where the work stops being about one app and starts being about systems that act on their own.
How to use this section
- Start with access. Being signed in is not the same as being allowed. This is the single most common and most damaging gap.
- Follow the money end to end. Not the happy path: the refund, the failed card, the duplicate notification, the payment that succeeds while the page dies.
- Find out what you are holding. You cannot protect or delete data you do not know you collected.
- Then make it explainable. If you cannot describe what your app does with data, you cannot answer a customer, a partner, or a buyer.
The honest line: nothing here is a penetration test, a security certification, or a legal review, and none of it makes an app "safe" as a finished state. These are read-off checks. You look at your own screen and answer honestly, and where something is short the result tells you what to look at next -- and says plainly when nothing is. That is a genuinely useful thing and it is not the same as an audit.
FAQ
What usually breaks first in an AI-built app?
Access control. The app checks whether you are logged in but not whether this particular record belongs to you, so any signed-in user can reach another user's data by changing a number in the address bar. It is invisible in a demo because a demo only ever has one user.
Is vibe-coded software inherently unsafe?
No. It is software that was built quickly by describing intent, so the risk concentrates in whatever the description did not mention. The code is often fine. The gaps are in access rules, failure paths, and money handling, the parts nobody thinks to specify.
Why do payments need more than a success page?
Because the browser can close, the network can drop, and the notification can arrive twice. A payment path that only works when the customer stays on the page will eventually take money and deliver nothing, and that failure looks like fraud to the person it happens to.
I found a key in my repository. What now?
Treat it as exposed and rotate it, rather than deleting the file and hoping. Removing a key from the current version does not remove it from the history, and rotation is the only step that actually revokes access. Rotate first, tidy the history second.
Do I need to know what data my app stores?
Yes, and it is usually more than you chose. Logs, analytics, error reports, and AI prompts all accumulate copies of things you never decided to keep. Knowing what you hold is the prerequisite for every other decision about it, including whether you should be holding it at all.
How do I check any of this without being an engineer?
By reading your own screens and answering specific questions honestly: open two accounts and try to reach one from the other, follow a real payment through to delivery, look at what your database actually stores. The checks are observational, not technical.
Find out what your app does when you're not watching
The Vibe-Coded App Hardening Kit ($79) walks the gaps that survive a good demo. Or take the whole readiness slate with Past the Prototype ($459), ten drills covering access, money, data, and change control. One-time, instant download, yours to keep.
Harden your app ($79)
