A vibe coding MVP has one job: to find out whether people want what you are building. Vibe coding, which means building software by describing what you want to an AI tool and accepting the code it writes, does that job quickly and lets a non-technical founder test an idea before hiring anyone. The risk does not sit in the test. It sits in the moment the test quietly becomes the business: a customer pays, people you have never met sign up with their personal data, a freelancer needs to change the code, or an investor asks to see it.
This guide covers where that line sits, what to check once your MVP crosses it, whether to keep, harden or rebuild, and which EU rules apply to a vibe-coded MVP. The basics of MVP development and the full path to shipping AI-built products safely each have their own guide.
TL;DR
Vibe coding an MVP is a sound way to test demand. A vibe-coded MVP stops being a test when people start to depend on it: from then on, the code has to protect their data and money, and someone other than the AI tool has to understand it.
- Five signals mark the change: a first paying customer, personal data from people you do not know, a second person changing the code, an investor asking to see the product, and connections to payments or other companies’ systems. One signal means run the checks; two or more mean get an independent review before you grow further.
- Three check groups come first: data and access, money flows, and ownership and handover. Data and access leads: broken access control is A01 in the OWASP Top 10:2025.
- Keep, harden or rebuild follows from what the checks find: harden when the issues sit in access rules, keys and error handling; rebuild one component when authentication, payments or the data model is structurally wrong.
- GDPR has no MVP or test-phase exemption: where an MVP processes personal data within the scope of Article 3, it needs a privacy notice and lawful basis, Article 28 processor agreements and an Article 33 breach procedure; a chatbot adds the EU AI Act Article 50 disclosure, applicable since 2 August 2026.
What vibe coding an MVP is good for
Vibe coding fits an MVP whose job is learning: does anyone want this, will they sign up, will they pay? Collins Dictionary named “vibe coding” its Word of the Year for 2025 and describes it as using AI, prompted in natural language, to help write computer code. For an MVP, the smallest version of a product that tests one core assumption with real users, that method changes who can run the test: a founder who builds the MVP with AI can describe the core loop, try it with users and change it after the first user conversation.
The upside is specific. The founder describes a change and tests it without waiting for a development team, the upfront spend stays small, and nobody has to be hired before demand is proven. That makes vibe coding a sensible starting point when the question is whether anyone wants the product, because the cost of being wrong is a discarded idea rather than a discarded codebase.
So is vibe coding viable? For validation, yes. As the long-term product, its viability depends on whether the code passes three groups of checks: data and access, money flows, and ownership and handover. An AI tool optimises for code that runs; it does not decide on its own who should be allowed to see which record.
The indicator to watch is simple. Once your MVP has answered its validation question, its job is done, and the next decision is about what you ship to customers.
Vibe-coded MVP vs a product customers rely on
A vibe-coded MVP has to prove that something works when the founder uses it. A product customers rely on has to keep working, and keep each customer’s data separate, when strangers use it in ways nobody planned. That is why “it works in the demo” is weak evidence. In a Stanford user study, Perry et al. (ACM CCS 2023) found that participants with an AI code assistant wrote less secure code than those without one, and were more likely to believe their code was secure. The study used an earlier generation of assistant; the gap it measured, between code that looks finished and code that is safe, is what Table 1 compares.
| Dimension | What to check in a vibe-coded MVP | What customers relying on it need |
|---|---|---|
| Login and access rules | Whether a customer can see another customer’s order by changing a number in the address bar | Every request checked against who is asking, on the server |
| Database and personal data | Whether database access rules are switched on, and which personal data is stored that the product does not use | Access rules per user or customer account; only the data the product needs |
| Payments | Whether an order is marked paid because the browser said so | Payment status confirmed by the payment provider, on the server |
| Error handling | What a user sees when a step fails halfway, and whether the failure is logged | Clear failure states and a log someone reads |
| Tests | Whether anything checks sign-up, payment and data access after a change | Automated tests around the flows that touch money and personal data |
| Deployment and rollback | Whether a release can be undone if it breaks sign-up | A repeatable release and a way back to the last working version |
| Who understands the code | Whether anyone besides the AI tool can explain how sign-up, payment and data access work | At least one person who can explain and change those flows |
| Documentation | Whether settings, keys and third-party services are written down anywhere | A short record of services, settings and who owns each |
Keep the vibe-coded MVP as the base when the core data model is sound and the access rules can be fixed in place. Plan a rebuild of specific parts when the data model or the authentication is wrong, because every feature built on either inherits the flaw. The security failure modes behind these rows are covered in vibe coding security risks .
Five signs your MVP has stopped being a test
A vibe-coded MVP stops being a test when someone other than you starts to depend on it. These five signals mark that point:
- The first paying customer. Money changes the expectation from “try this” to “this should work”, and a payment error now costs someone else.
- Personal data from people you do not know personally. Under GDPR Article 4(1) , personal data is any information relating to an identified or identifiable person, so an email address in your user table already counts.
- A second person needs to change the code. A developer or freelancer who cannot follow how sign-up, payment and data access work will either slow down or change things they do not understand.
- An investor or acquirer asks to see the product or the code. Questions about who understands the code and how data is protected become part of technical due diligence .
- The product connects to payments, customer systems or other companies’ data. Each connection adds credentials to protect and a failure that reaches beyond your own product.
We recommend a simple rule. One signal means run the three check groups: data and access, money flows, and ownership and handover. Two or more signals mean get an independent review before you grow further, because at that point a missed issue affects paying customers, their data and your investor conversations at once.
What to check before customers rely on your vibe-coded MVP
Three groups of checks come before customers rely on a vibe-coded MVP: data and access, money flows, and ownership and handover. Start with data and access. Broken access control is ranked first, as A01, in the OWASP Top 10:2025 , the reference list of web application security risks, so it is the category to rule out first when time is short.
These checks are specific to the MVP stage. For the full release check, use the production readiness checklist .
Data and access
The data and access check answers one question: can a user reach data that is not theirs? Log in as one test user, open a record, then change the ID in the address bar to one that belongs to another test user. If the record loads, the server is not checking ownership.
If your MVP stores data in Supabase, confirm that row-level security, a database rule that limits each user to the rows they are allowed to see, is switched on for every table that holds customer data. Our guide to Supabase RLS covers what to ask your developer. Check that no API key with write or admin rights sits in the code that runs in the browser; our guide to leaked API keys in AI products explains how keys leak and how to fix them. Finally, list the personal data you collect and remove what the product does not use: GDPR Article 5(1)(c) requires data to be limited to what is necessary for the purpose.
Money flows
The money flows check makes sure an order is only marked paid when the payment provider confirms it. A webhook is a message the payment provider sends to your server when a payment succeeds, fails or is refunded. Your server should act on that verified message, not on a “success” page the browser reaches.
Three checks cover the MVP stage. First, payment status is confirmed server-side from the provider’s webhook, and the webhook’s signature is verified before your code trusts it. Second, refunds and failed payments change the order status and notify the customer. Third, prices and discounts are set on the server, so nobody can lower a price by editing the request in their browser.
Ownership and handover
The ownership and handover check confirms that the product can be run and changed without the AI tool’s chat history. The code should sit in a repository, a version-controlled store of the code and its history, that your company owns, not only inside the AI tool’s account.
Environment variables, the settings and secret keys the app reads when it starts, should be documented: which services they belong to and who can change them. The test of this group is a conversation. A person other than the AI tool should be able to explain how sign-up, payment and data access work. If nobody can, a second developer starts by reverse-engineering your product.
Keep, harden or rebuild your vibe-coded MVP
What the three check groups find decides whether you keep, harden or rebuild a vibe-coded MVP; the way the code was written does not. Rebuilding by default throws away product decisions your users have already validated, from the flows they understand to the data you have learned to collect.
| What the checks find | Recommendation | Condition |
|---|---|---|
| Fixable issues in access rules, exposed keys and error handling | Keep and harden | The data model supports the next features and the fixes stay inside existing components |
| One area structurally wrong, such as authentication or payments | Rebuild that component | The rest of the codebase passes the checks and can call the new component cleanly |
| A data model that cannot support the next feature set | Rebuild more, starting with the data model | The validated flows and screens are kept as the specification for the rebuild |
Hardening means fixing the issues in place and adding tests around the flows that touch money and personal data, so the fixes stay fixed. The full decision between refactor or rewrite for an AI-built app has its own guide, including the signals that point to a rewrite.
Not sure whether to keep, harden or rebuild? An AI-built product review of your vibe-coded MVP separates what blocks paying customers now from what can wait, and gives your team a clear order for the fixes. Request a product review
What drives the cost of the next stage
The cost of taking a vibe-coded MVP to a product customers rely on depends on six drivers. The first two follow directly from what the checks find:
- The number and depth of fixes found. Several small access-rule fixes cost less than one structural problem in authentication.
- Whether the data model changes. A data model change touches every feature that reads or writes that data.
- Payment and integration complexity. Each payment method, customer system or partner connection adds work and tests.
- AI model and API running costs. If the product calls an AI model at runtime, usage-based fees grow with the number of users.
- Hosting and monitoring. A product customers rely on needs logs, alerts and backups the MVP may not have.
- Who maintains it. An in-house developer, a freelancer and an external team each carry a different ongoing cost.
For budgeting, our guide to AI app development cost separates build costs from running costs. Prices for a review or fixes depend on scope, so Sunbytes advises on them case by case.
Which EU rules apply to a vibe-coded MVP
The GDPR applies to a vibe-coded MVP as soon as the MVP processes personal data within the territorial scope of Article 3 GDPR : when your company is established in the EU and processes the data in the context of that establishment, or, for a company outside the EU, when the MVP offers goods or services to people in the EU or monitors their behaviour there. That can already be the case during testing. Whether the users are testers, acquaintances or paying customers does not decide whether the GDPR applies, and there is no exemption for MVPs or start-ups. Organisation size changes some duties, such as the conditional record-keeping exemption in Article 30(5) for organisations under 250 employees, but not the four that matter most at the MVP stage:
- A privacy notice and a lawful basis. Article 13 sets out what users must be told; Article 6 lists the lawful bases.
- Processor agreements. Where a database, hosting or AI model provider processes personal data on your instructions, Article 28 requires a contract with it. Confirm each provider’s role and agreement before real users sign up.
- A breach procedure. Under Article 33 GDPR , the controller notifies a personal data breach to the competent supervisory authority without undue delay and, where feasible, no later than 72 hours after becoming aware of it, unless the breach is unlikely to result in a risk to people’s rights and freedoms. A notification made after 72 hours must give the reasons for the delay. For a start-up whose only or main establishment is in the Netherlands, the competent authority is normally the Autoriteit Persoonsgegevens.
- Cookie consent. For a website or app aimed at Dutch users, ACM guidance on placing cookies says tracking cookies and privacy-sensitive analytics cookies need consent. Functional cookies and analytics cookies with little impact on visitors’ privacy may be placed without consent, provided you tell visitors you use them.
If your MVP includes a chatbot that talks to users, the EU AI Act Article 50(1) has applied since 2 August 2026: the provider of the AI system must design it so users are told they are interacting with AI, unless that is obvious to a reasonably well-informed person in the context. Whether your start-up counts as the provider depends on how the chatbot is built and offered, so assess that role with legal advice.
How Sunbytes reviews vibe-coded MVPs
Whether your MVP was vibe-coded matters less than whether it is ready for the customers who now depend on it. An AI-built product review from Sunbytes answers that question across the same ground as the three check groups: who can reach which data, how money moves, and whether anyone besides the AI tool can run the product.
Sunbytes software engineers and security specialists review the same product: its code, architecture, security, reliability and deployment. On the security side that includes authentication, permissions, cross-user access, exposed secrets, database rules and sensitive data flows. Because both disciplines look at one codebase, the findings go further than an automated scan. Each comes with its evidence, in a plan for what to fix now, what can wait and where to start.
The review does not assume a rebuild: your team can make the fixes, or Sunbytes engineers can fix the priority issues and check them again. Code and data access run under Sunbytes’ ISO 27001-certified information security management system, with Netherlands-led delivery and 15+ years and 300+ projects of software delivery behind the method.
If your MVP shows two or more of the five signals, talk to us about an AI-built product review.
