Turn Ideas Into Working Apps, and Actually Ship Them

This is general information about building and shipping software. It is not a security assessment of any specific application, and it does not replace review by someone who can read your code.

The prototype was never the hard part

You can describe an app and have something running the same afternoon. That is real, and it is a genuine change from a few years ago.

It also solved the step that was never blocking anyone. Ideas were not scarce. Working demos were not what stood between a founder and a product. The wall was always the distance between something that works when you use it and something that survives other people using it.

That distance has not shrunk. If anything it feels longer now, because the first stretch got so fast that the remaining work is a surprise.

What breaks between demo and users

Generated code is optimized to satisfy the description you gave. Nobody described the failure cases, so nobody handled them.

• Nothing rejects bad input. The demo works because you typed what you meant. Real users paste a spreadsheet cell into a phone number field on their first attempt.
• Authorization was never written. There is often a login, which is authentication. Whether user A can read user B's records by changing a number in the URL is authorization, and that check tends to be missing entirely.
• Secrets are in the wrong place. API keys committed to the repository or shipped to the browser, where anyone can read them and spend your money.
• There is no cost ceiling. An app calling a paid model with no rate limit is an open tab. One loop or one bored visitor is a real bill.
• Nothing tells you it broke. No logging, no error reporting. The first report is a user who bothered to write in, and most do not bother.

None of these are exotic. They are the standard list, and they are absent because generated code answers the question asked, not the questions nobody thought to ask.

The order that gets you shipped

Fix by blast radius, not by how uncomfortable each one feels.

Money and data first. A cost ceiling and a rate limit, because a runaway bill happens in hours. Then authorization, tested by logging in as one user and trying to reach another user's data by hand. That single test catches the most common serious flaw in small apps.

Then secrets out of the client and out of the repository, then input validation on anything that touches storage, then error reporting so failures reach you instead of accumulating silently.

Notice what is not on that list. Test coverage, clean architecture, and the framework debate can all wait. They matter for the version you maintain for years, not for the version that decides whether anyone wants this.

The honest tension

Every hardening item above is a reason not to ship today, and shipping today is how you find out whether the thing is worth hardening.

Ship-it-now advice ignores that a data leak in week one ends the project. Harden-first advice ignores that most projects deserve to die unlaunched and polishing them is wasted effort.

The split that works: the money and data items are non-negotiable because their failures are unrecoverable, and everything else is negotiable against how many users you have. Ten friendly testers and a public launch are different risk situations, and treating them the same is how people either leak data or never ship.

Scope is the other lever, and the cheapest one. Most first versions handle three cases when the real question needs one. Cutting to one is faster than hardening three.

Before it goes public

The uncomfortable step is having something check the code instead of reading it yourself. You will read past what you wrote, and you will read past what a model wrote for you even faster, because it looks finished.

Our Vibe-Coded App Pre-Launch Security Gate ($79) runs that pass deterministically and returns a verdict on whether the app is ready for users, with the fix-first item where a control is short, not a list of everything. It grades the app, not you, which is the part that makes it usable the day before launch.

Frequently Asked Questions

Why do AI-generated apps break when real users arrive?

Generated code is written to satisfy the description it was given, and nobody describes failure cases. So input validation, authorization checks, rate limits and error reporting are usually absent. The demo works because the person testing it types what they meant. Real users do not, and nothing in the code was written to handle that.

What is the difference between authentication and authorization here?

Authentication is verifying who someone is, which generated apps usually include as a login. Authorization is checking whether that person may access a specific record, which is frequently missing. The practical test is to log in as one user and try to reach another user's data by changing an identifier in the URL.

What should I fix first?

Order by blast radius. A cost ceiling and rate limit come first, because a runaway bill against a paid model happens within hours. Authorization comes second, because a data leak is unrecoverable. Then secrets out of the client and repository, input validation, and error reporting so failures reach you instead of accumulating silently.

Do I need tests and clean architecture before launching?

Not for a first version. Test coverage, architecture and framework choice matter for software you maintain for years, not for the version that determines whether anyone wants the product. The items that cannot wait are the ones whose failures are unrecoverable, which means money and data, not code quality.

How do I decide how much hardening is enough?

Scale it to your actual exposure. Ten invited testers and a public launch are different risk situations. Money and data protections are non-negotiable at any size because their failures cannot be undone. Everything else scales with user count. Cutting scope is usually cheaper than hardening, since most first versions handle more cases than the question requires.