AI Wrote Your App. Should You Ship It?

Short answer: not without a review. AI coding tools like Cursor, Claude, and Replit can produce a working product in days, but "working" and "safe to put in front of paying customers" are different bars. AI writes code that runs, not code that has been checked for who can access what, what happens on bad input, or what an attacker does when they poke at it deliberately. Before you ship a vibe-coded product, run it through a QA pass, a security review, some fuzzing, and ideally a penetration test. That is the short version. Here is the long version, including what actually tends to go wrong and what it costs to check.

Why "it works" is not the bar

You built it with AI, described what you wanted, and watched a working product appear in days instead of months. That is genuinely great, and it is a fraction of the cost of hiring a development team to build the same thing from scratch. But before you put it in front of paying customers or an investor, there is a question worth sitting with: should you actually ship it as is?

The uncomfortable truth is that AI is not there yet when it comes to getting the hard parts right. It is very good at the happy path, the flow you described in your prompt, and quietly bad at the edges: the security model, the assumptions baked into the data, the thing that only happens when two users hit the same feature at once. Code that looks correct and runs is exactly what makes this risky, because there is nothing about a clean-looking function that tells you whether it checks who is allowed to call it.

Where AI-built code tends to break

Security holes. AI routinely produces code with missing authorization checks, injectable queries, leaked secrets in client-side code or repos, and access-control mistakes where one user can see or edit another user's data. This is not the model being careless. It optimizes for something that works on the first pass, and insecure code very often works fine right up until someone tries to attack it.

Logic flaws. The subtle business-logic bugs are the ones that survive a demo and surface in front of your first real customers: the wrong assumption about who can do what, the discount that stacks when it should not, the state transition nobody described in the prompt because nobody thought to.

Overlooked edge cases. AI builds what you asked for. It does not push back on what you forgot to ask for. The empty state, the concurrent request, the malformed or oversized input, the behaviour that only shows up once you have real traffic instead of a handful of test accounts.

Dependency and configuration drift. AI tools happily pull in packages, wire up cloud storage buckets, and generate infrastructure config to get something running quickly. Left unchecked, this can mean outdated or vulnerable dependencies, storage buckets left open, or environment variables and API keys committed straight into the codebase.

This is not an argument against vibe coding

To be clear, building with AI is a good idea. Shipping something unchecked because it was built with AI is not. The right mental model is the same one a sensible team uses for any code: fast building is great, but you still review it, test it, and try to break it before customers do. The only real difference with AI-generated code is that the reviewer needs to be a little more suspicious of it, because the code carries none of the hesitation a human writes in when they are unsure of something. A human developer leaves a comment saying "not sure this is safe, revisit." AI does not.

The Canadian wrinkle: privacy law does not care how the code was written

If your product touches personal information, PIPEDA still applies, and if you have users in Quebec, Law 25 applies on top of it with its own breach-notification and privacy-by-design expectations. Regulators and enterprise buyers do not ask whether your access-control bug came from a human developer or an AI assistant. A leaked customer record is a leaked customer record whether it happened in a startup in Waterloo, a fintech in Toronto, or a SaaS company selling into Quebec from Montreal or Vancouver. If you are planning to sell into regulated industries or to enterprise customers anywhere in Canada or the US, a security review before launch is often the difference between closing a deal and getting stuck answering a security questionnaire you cannot pass.

How to check a vibe-coded product before you ship

Four things catch the vast majority of problems, and they build on each other rather than replacing one another.

• Quality-assurance pass. A structured walk through the actual flows, not just the ones you tested manually, to find broken states and wrong assumptions before a customer does.
• Security review of the code and architecture. A manual look at auth, injection points, secret handling, and how data flows between the frontend, backend, and any third-party services the AI wired up on your behalf.
• Fuzzing. Throwing malformed, oversized, and unexpected input at the running app to see what falls over, which is often the fastest way to find the crash or data-corruption bug nobody thought to test for.
• Penetration testing. Treating the live product the way a real attacker would, chaining small weaknesses together rather than checking them one at a time in isolation.

Together these tell you what is broken, what is exploitable, and what to fix, before it is a customer, an auditor, or an investor's technical diligence call finding out for you instead. If you want the fuller picture of how we structure a security engagement end to end, our security solutions page walks through the full range from a single review to ongoing testing.

What this actually costs

One reason founders skip this step is the assumption that a proper security check costs as much as the build did. It does not have to. A scoped penetration test through traztech starts from 1,000 CAD, sized to the actual product and risk in front of you rather than a generic checklist, and priced to make sense for an AI-built MVP rather than an enterprise platform. You can see how that scales with the size and complexity of the product on our pricing page.

Where we come in

This is exactly what our vibe-coding QA and security review is built for. We QA, security-review, fuzz, and penetration test AI-built products, led by a published security researcher with five CVEs to his name, including a CVSS 9.1 kill-switch for a Mirai-family botnet, and it still costs a fraction of what standing up a full development team to redo the same work would run. If you have shipped or are about to ship something built with AI and you want to actually know it is good before your customers find out otherwise, get it reviewed or read more on our security page.

The specific bugs, not the general worry

Abstract warnings about AI code are hard to act on, so here is the concrete list we keep finding in AI-built products. Object references with no ownership check, where an endpoint fetches a record by the id in the URL and returns it to whoever asked, so changing 4182 to 4183 shows you another customer's invoice. Row-level security never switched on in a hosted database such as Supabase or Firebase, leaving tables readable by any authenticated user and often by anonymous ones. The service role key shipped to the browser, because the model needed a key that worked. Authorization enforced in the interface only, where the admin button is hidden from ordinary users but the route behind it checks nothing. Webhook handlers that skip signature verification, so anyone who learns the URL can post a payment-confirmed event to your billing logic. And seeded test accounts with predictable passwords left live in production.

Notice the pattern. Every one behaves perfectly in the demo, because the demo is one logged-in user doing the thing you asked for. They appear only when a second user exists, or when someone edits a request by hand.

The ninety-minute pass you can do yourself

Before you pay anyone, do this. Create two accounts in different tenants, put data in each, then open the browser network tab and replay a request from the first account with an id belonging to the second. If you get data back, fix that before anything else. Next, search the repository and the built frontend bundle for keys and secrets, including the git history, since a rotated key still sitting in a commit is still exposed. Then log out and call a few of your API routes directly with no session. Finally, confirm each admin route checks a role server side.

None of that needs tooling, and founders who do this pass first get more value from a paid test, because the tester spends their hours on chained weaknesses instead of on the obvious.

If your product uses an LLM, the model is an input surface

Plenty of AI-built products also call a model at runtime, which changes the threat picture. Anything the model reads is untrusted input, including retrieved documents, uploaded files and text a user pasted from elsewhere. If your assistant can call tools, query a database or send an email, instruction text hidden inside a document can reach those capabilities. The controls are unglamorous: the model gets its own least-privileged credentials, every tool call is authorized against the requesting user rather than the service, output rendered into the page is escaped, and a spend limit stops scripted abuse becoming a five-figure API bill overnight.

What makes a test cheap or expensive

Penetration testing from $1,000 is real for a small AI-built product, and the scope drivers are worth knowing before you ask for a quote. A test is cheaper when you hand over a staging environment mirroring production, two accounts per user role already created, a description of what would be worst if it leaked, and a list of routes or an API specification. It costs more when the tester has to map the application by hand, when payments or health data are in scope, when tenants have genuinely different permission models, or when testing has to happen in production without breaking live customers.

Be clear about what you are buying, too. An automated scan tells you which dependencies have known vulnerabilities and which headers are missing. It does not find the ownership check that was never written, because no scanner knows whose record that is. Our security work starts from that distinction.

When not to pay for any of this yet

If what you built is an internal tool used by four colleagues, or a prototype with no real users and no personal information in it, do not buy a penetration test. Do the ninety-minute pass, turn on multi-factor authentication for anything that reaches production, and keep building. The same holds if the product is being rewritten next month, since you would be paying to find bugs in code you are about to delete. Spend the money when real customer data lands in the database, when you take payments, or when a buyer's security review is between you and a signature. If you are unsure which side of that line you are on, tell us what the product does and we will say plainly whether it is worth testing yet.