Can you vibe-code an actual product end-to-end?

Definitions

I define “vibe-coding” as delegating almost all implementation and engineering decisions of a project to AI and assuming that it’ll make the right choices when needed. The prompter focuses on product decisions, making very limited technical suggestions, and does not contribute to structuring the code. For example:

I also crudely define an “actual product” as a B2C web or mobile app that solves no more than a few problems, can process user payments, stores user data, has a frontend interacting with a backend, and, crucially, has users willing to pay for it. Moreover, an “actual product” is not highly vulnerable to any critical production failures (e.g., frequent downtime, data loss, secrets exposure, etc.).

Of course, this definition excludes a huge chunk of possible software products, and that is intentional. The goal of this post is to focus on a specific kind of product category (perhaps the easiest kind) and examine what AI can achieve in that category. Every claim that follows is with respect to this specific kind of product and not any others. Also, this is being written in mid-July 2026 in the context of Fable 5-tier models. The purpose is to get a lay of the land in the current moment. Things may change quickly.

Bottlenecks

Note: I won’t address whether or not AI has sufficient UI/UX taste to plan a good product (it doesn’t), and will assume that the prompter is handling that and is good at doing so.

Given that someone has good product taste, the bottlenecks to them executing that vision are:

  1. Making good enough (not necessarily great) engineering decisions, both architecturally and at a granular line-by-line level.
  2. Identifying and fixing non-obvious bugs both pre- and post-release. During development, preventative measures should be taken against critical production failures which are potentially harmful, either for the developer or the users. Furthermore, it should be made feasible to fix whatever problems may arise, small or catastrophic, even if the product is live.

The question is: can AI handle those two, and if yes, to what extent?

To answer this, we must answer some subquestions:

  1. If prompted to do so, can AI take the vision for a product and plan out the platforms/dev tools/general architecture needed to fulfill that vision?
  2. If prompted to do so, can AI audit the code (through tests or other means) to identify and fix significant bugs? This applies to both pre-launch and post-launch.
  3. Does AI have the skill to implement great UI/UX if guided by the vision of the prompter?
  4. Does AI structure the project and write the code in such a way that it is maintainable months down the line, at least enough so that a train wreck doesn’t occur?
  5. Does AI avoid critical production failures by independently accessing and building with reliable “legos”, i.e., platforms and dev tools which reduce the need for AI itself to handle security, payments, scalability, databases, etc.?

Answering 1-4

I believe that AI can take the vision for a product and plan out the general architecture for it well enough, but it needs to be prompted to do so. What it is not good at is filling in the gaps, meaning that it can blurt out a viable tech stack but it doesn’t really understand how that stack will actually fit together and whether it accounts for the whole product vision. What’s needed from the human here is not necessarily a technical contribution, but rather a high-level examination of the architectural choices to ensure that the architecture can actually achieve the goal.

As the project evolves and grows, it is also essential for the human to remind the AI to stay aligned with the original choices, as well as to ensure that any updates to the architecture are only made for good reason. It is not enough to settle on a stack at the beginning, write it to CLAUDE.md, and then go ham for the next week expecting that it will properly fulfill what it set out to do with the initial stack.

Thus, the answer to the original question, “can you vibe-code an actual product end-to-end?”, is no, because the developer must invest time into considering the software architecture. But there is still much to consider regarding the question of just how much you can delegate to the AI in the development of such a product, which is what I will now evaluate.

AI can, if prompted to do so, audit code (through tests or other means) to find and fix significant bugs. In fact, it often does this independently, without prompting. It’s not great at it, but it’s good enough.

Furthermore, it definitely has the skill to implement great frontend designs even without guidance on how to do so. It just needs to know what your vision is, and giving it a reference really helps with this. Without a reference, results are initially underwhelming, but after many iterations results become pretty good.

Now, on to code cleanliness and maintainability. In the last few months AI has become good enough to not cause a train wreck. This is due to improvements in context windows, harnesses, and the models themselves. While it does inflate the codebase unnecessarily, and the codebase does become less maintainable over time, and the AI does get carried away, it doesn’t fundamentally undermine our “actual product” definition to such an extent that the answer to our fourth question becomes “no”. For a B2C product of the kind I describe (one that only solves one or a few problems and isn’t very complicated), codebase organization/cleanliness is less important than iteration speed once the former meets a certain bar. Coding agents now meet that bar out of the box. Furthermore, a naive-sounding yet reasonable argument is that 6+ months from now, we’ll likely have significantly better coding agents which are capable of rectifying a significant portion of the maintainability issues that arise from current AI models; if the codebase can survive until then, it’s probably fine.

With that out of the way, it’s time to answer the final question, which deserves its own section.

Does AI avoid critical production failures by independently accessing and building with reliable “legos”, i.e., platforms and dev tools which reduce the need for AI itself to handle security, payments, scalability, databases, etc.?

This question is important because if the answer is “yes”, then a lot of load is lifted off of the AI and and instead the main bottleneck is how well AI fills in the gaps between these legos, rather than having to reinvent the wheel from scratch with each new product. Furthermore, if these legos are very accessible to coding agents by, for example, having a well-known CLI, it would be possible to delegate even more to AI.

From my own testing it’s apparent that AI does not independently access and build with such legos, but it does make use of them if directly prompted to structure the architecture around legos which are useful for the project and really accessible to the coding agent. That being said, this doesn’t mean building a product is as easy as giving AI a prompt to use “Supabase for data, Stripe for payments, and Sentry for observability” and then hoping it can handle the rest. There are really twelve crucial components which differentiate a product that’s “production ready” from a product that starts coming apart a week after launch. They are as follows:

  1. Authorization: constraining what a logged-in user can do.
  2. Observability: actually noticing if something on this list goes wrong.
  3. Abuse & rate limiting: ensuring that bots, scrapers, or malicious actors don’t destroy your software (or your wallet) by hammering a button or endpoint.
  4. Data storage: storing data in a durable database, ensuring there are backups, and changing schemas without breaking the software.
  5. Secrets management: storing, securing, and reading the secret keys which allow the app to interface with various platforms, such as databases providers or LLM APIs.
  6. Payments: charging the user through subscriptions or one-time fees, and handling taxes and refunds. Another key aspect of this is ensuring that your log of “who paid what” is in sync with reality.
  7. App security: protecting against common attacks such as executable string injection or malicious file uploads.
  8. Authentication: proving that a user is who they claim to be with usernames, passwords, 2FA, etc.
  9. Deployment: managing app versions, testing and pushing updates, and being able to revert if something goes wrong.
  10. Privacy & legal compliance: following established standards for user privacy and making sure you don’t get sued.
  11. Reliability: minimizing downtime and handling dependency failures.
  12. Scalability & performance: setting up the app so that it’s efficient and handles a growing user-base gracefully.

The “vibe-codeability” of these 12 components depends on 3 questions:

  1. Is a failure noticeable just by using the app as a regular user would? For example, if you’re not able to log in to the app because something’s broken, you’re going to notice that when you try to log in to the app through the UI, making this kind of failure more noticeable.
  2. Are there legos which handle this component so that you don’t have to worry about it?
  3. How much damage would a failure actually cause? For example, the app getting slower isn’t as bad as you losing some money, which isn’t as bad as your users’ data getting compromised.

If a failure of a given component is easily noticeable, absorbed by an existing lego, and causes minimal damage, we would say that it’s very vibe-codeable, and vice-versa.

Now, in order of least to greatest vibe-codeability, let’s examine each component. We’ll note the most important factors for each component and then conduct an overarching assessment about the vibe-codeability of an actual product.

1. Authorization

A failure in authorization is not made apparent through plain UI-testing, because authorization is about what the UI doesn’t offer. Clicking around on your web app isn’t enough to notice that your app offers functionality which it shouldn’t to certain users. And failures are highly damaging, because they might allow users to read, modify, or delete other users’ data.

Furthermore, what different categories of users can and can’t do depends on your specific product. Since there is so much variation in what different businesses make available to different users, there isn’t a pre-packaged lego that handles this for you. And the more features your app has, the more difficult it becomes to manage this, because authorization is essentially a matrix of resources * roles * actions.

That being said, we’re not completely in the void here. Postgres, one of the most widely used open-source databases, has a feature called Row-Level Security (RLS). It automatically enables default-deny, meaning that if you don’t write a specific policy for a feature, it’s disabled for everyone. But this still means that someone has to write the rule, and if you’re vibe coding, that someone is AI. Supabase does have a “Security Advisor” linter which scans your database and lets you know about various problems, but it still doesn’t handle the actual coded rules. So it’s left to the coding agent, and a coding agent could just be ignorant and write a rule that’s too lenient.

There’s another pitfall too. Say that you’re using Stripe, and someone makes a payment, and you need to update your table to mark that user as “paid”. You get the request to do so from Stripe itself because that’s what’s processing the payments. Since this request isn’t coming from an actual user, you need to make use of a master key handed to you by your platform of choice. This key lives in your environment file in your backend and solves any permission errors. The problem is that the lego doesn’t stop AI from just using that master key when it lands on a permission error which it deems to be “not that deep” when, in fact, it might be that deep.

2. Observability

While you can notice some failures just by using the app, there are many failures which simply won’t appear to you in testing. For example, the app might break for another user, and you’d have no idea. Thankfully, the legos here are actually good: we have Sentry for error tracking, Datadog/Axiom/Better Stack for logs, and Checkly/UptimeRobot to ping you if something goes down.

The problem is that you need to know to install these legos because AI doesn’t do it by default. And errors compound if you don’t have proper observability set up because they just go unnoticed. The car would be veering off the road while you’re asleep at the wheel. So the damage potential is very high if this isn’t handled.

3. Abuse & rate limiting

There might be scripts that try to hit your endpoint 50,000 times in an hour, and you can’t test that manually in your app’s UI. And some of your endpoints might cost money per call, so you can rack up a heavy bill if someone hammers those endpoints.

That being said, this is similar to observability in the sense that if you know about it, it’s not a difficult problem to solve with the assistance of coding agents, because good legos exist: Upstash, Ratelimit, Cloudflare, Vercel’s firewall, and Arcjet. And AI APIs allow you to set cost limits. So, yes, Cloudflare can act as a “global monitor” by sitting in front of your app and blocking obvious bots across all endpoints. But for specific, cost-based rate-limits, like a call to an AI API which costs $0.04 each time, a global switch isn’t sufficient. You need specific rate limits in place for that kind of functionality.

Overall, rate-limiting is basically something you just have to check off the checklist, but it’s a non-trivial problem because it has to be thought of for many features.

4. Data storage

For the problems that everyone thinks about, the legos are great. Managed Postgres providers (Supabase, Neon, RDS) handle a lot of the important stuff like replication and backups. But this doesn’t protect you from a command directly to your database which, for example, alters a column, succeeds, and subsequently breaks your app while it’s live.

There’s a more subtle problem as well: you might roll out an update to your app in tandem with a database migration. Then you realize something is wrong with the app so you roll it back to the previous version. But your database is still at the updated version. Now your app and database are out of sync, potentially breaking things even more. Problems like these aren’t automatically managed by the existing legos.

5. Secrets management

If a secret key leaks, it changes nothing about how the product behaves, so the leak is invisible. The good thing is that there are excellent legos for secrets management (Vercel, Railway, Fly, AWS). They offer encrypted environment-variable stores as defaults, and secret managers like AWS Secrets Manager even rotate keys for you.

Yet that doesn’t prevent keys from ending up in places where they shouldn’t be. A key could end up committed in a public GitHub repo, or put raw in frontend code which users can see in the browser. The legos don’t protect against this kind of failure.

6. Payments & billing

Stripe is the big dog here and handles pretty much everything you need. Furthermore, payment failures usually become apparent quickly, through avenues like user complaints. They likely won’t go unnoticed for long.

That doesn’t mean we’re in the clear with this one, though. The main problem is that you have to keep track of who paid what and update your server accordingly. The wrong way to do this is using the browser’s JavaScript to tell your backend that a payment was processed. This is wrong because anyone can open dev tools in their browser, replay the “payment processed” request, and get the product for free. The right way to do it is to check for confirmation directly from Stripe. Since this isn’t handled for you by Stripe itself, it’s important to be mindful of.

7. Application security

A failure of this component is often invisible in use, but attacks in this category (such as SQL injection or cross-site scripting) have been around for a long-time and are therefore broadly handled by modern frameworks which AI defaults to. You have to go out of your way to expose yourself to these kinds of attacks.

But it’s a different story if your app has file uploads. You need to limit the number of files a user can upload as well as the size of each file. Attackers can also use files to inject a script into your server, or HTML which your app then serves to users. If users can download each other’s files on your app, your app might end up distributing malware. And if you process the file in any way, for example by parsing it, your file-processing code could get exploited by certain kinds of file inputs and be an entry-point for an attack.

The good thing is that legos exist to handle a lot of this. Code execution from an uploaded file on your server is prevented by storage platforms like AWS S3 and Supabase Storage. Uploadthing and Cloudinary handle certain configuration details (size caps, type validation, etc.). Parsing APIs (AWS Textract, Google Document AI) process files and move the attack surface from you onto themselves. But AI doesn’t just go for these by default.

8. Authentication

Since this is a generic problem that’s pretty much the same for every company, a number of great legos exist to solve this (e.g., Supabase Auth, Clerk). What’s up to you is to ensure that your backend verifies a user requests using the token for the user’s frontend given to you by the auth provider. Otherwise anyone, logged-in or not, can make requests.

9. Deployment and rollback

This component determines how fast you can undo failures in the other components, and whether or not you can properly update your app. Fortunately, legos exist for this one as well (Vercel, Netlify, Railway, Fly). If you push to Git they can deploy to production for you, they keep immutable versions of your different deployments, and they allow you to reverse a deployment quickly if needed. What’s important to know is that, in order to test deployments, you must use a staging environment and usually a second database rather than your main production database, otherwise you might break the live app while testing stuff out.

Nothing about using a product tells you if you’re compliant. This is also a unique component because it’s not really a software problem. One example of a policy is (on a state-by-state basis) the requirement to allow users to delete their own account and data. This is non-trivial because in order to do this you need to keep track of where each user’s data lives so that you can actually delete it for them if they want to delete their account.

Overall though, this legal stuff becomes a worry with scale rather than for a small B2C app getting off the ground. Usually, harm in this category is reversible, and legal consequences are financial and negotiable. You should just make sure to have policy pages and consent banners in the right place, as well as to keep track of where data lives for a given user.

11. Reliability

A failure of this component is both visible in use (if your app is down, you’ll know), and it’s also absorbed by a lego. If you’re building on legos, downtime is usually the result of a vendor going down (like Vercel or Cloudflare), but fortunately their uptime is really good. The problems arise when your app doesn’t properly handle when a dependency fails. That’s when a third-party’s failure becomes a crash or a half-completed operation in your app, and you want to avoid that.

12. Scalability & performance

A failure here is clearly visible — you can tell when your app is slow just by using it. And we have good legos here too: serverless hosts. A serverless host is a host that (contradictory to the name) still uses servers, but you don’t have to worry about the servers. What the host does is takes requests to your backend and creates an instance of your function to respond to it. They scale things for you and you pay per request rather than per hour of uptime. Some examples of such hosts are Vercel and AWS Lambda. Furthermore, managed Postgres providers like Supabase run your database for you and handle scaling.

If you want your app to work well globally, many of the big providers (e.g., Vercel) also use Content Delivery Networks (CDNs) by default so that your app’s frontend is cached around the world and someone in Tokyo can use your app with high performance even if you’re in the U.S.

Overview

Now that we have an understanding of these components, let’s revisit our original question: can you vibe-code an actual product end-to-end? Using our original definition of vibe-coding (delegating almost all implementation and engineering decisions of a project to AI and assuming it’ll make those decisions for you when needed), the answer is no. Yet none of the above are really the bane of a vibe coder’s existence. They just require a vibe coder to be more careful. You can get pretty close to vibe coding with targeted time investments and attention towards the following areas:

If you’re wondering about that last one, the ASVS is a framework from the non-profit OWASP which lists specific, testable security requirements that a web-app should adhere to. It’s organized into three tiers (L1-L3). L1 is the baseline and L3 is for systems where a breach might be catastrophic.

By taking these measures—which can be done collaboratively with AI—one can significantly reduce the chances of their web app coming upon some catastrophe, even if they use AI to write all the code. It’s no longer vibe coding because you have to take some care with this stuff, which might kill the vibe, but it’s still really, really fast compared to what was possible before AI.