VoraFly: From Vibecode to Production Failure

I knew VoraFly was probably vibecoded the moment I landed on it.

That was my first impression, based purely on the product itself. The interface felt like a collection of screens assembled to demonstrate features rather than a serious operational system designed around the people who would actually use it. There were emojis everywhere, playful interface elements, generic dashboard cards, and workflows that felt heavily centered around entering and managing records.

For a school-management product intended for formal organizations, I found the presentation strangely unserious. More importantly, the product did not give me the impression that it was designed around reducing administrative work. It felt more like another system that school staff would have to maintain.

At that point, my conclusion was fairly simple: this looked like another piece of vibecoded SaaS. Then I started testing it. Almost every subsequent discovery made my initial judgment look more charitable than it should have been.

What began as a casual assessment of a questionable-looking school-management application turned into a case study involving payment environment separation, production financial state, account assurance, input validation, referral attribution, subscription activation, auditability, and commission accounting.

The most concerning part was not any single vulnerability. It was the way several seemingly independent workflows trusted one another without sufficiently validating the state being passed between them.

A mocked payment could become production wallet value. That wallet value could purchase a production subscription. That subscription could generate a referral commission.

At that point, this was no longer just a badly designed application. It was an application whose trust boundaries appeared to have been designed with the same casualness as its UI.

How I Found VoraFly

I did not go looking for VoraFly. I encountered it through its own partner acquisition campaign.

The company was actively recruiting partners and advertising a 20% commission structure, with commissions of roughly ₦2,000 to ₦10,000 per school and fast payouts. That immediately made the application more interesting from a security perspective. A product sitting behind a closed beta is one thing; a product actively recruiting strangers into a revenue-generating referral program is another.

The partner program meant that there were already economic incentives attached to the application. That makes identity assurance, payment integrity, referral attribution, and commission accounting considerably more important than they would be for an isolated prototype.

I created an account and started using the application as an ordinary user. I did not begin with sophisticated exploitation. I simply followed the workflows the application itself exposed. That was enough.

The Product Already Looked Like Vibecode

Before getting technical, there was the product itself.

The interface immediately gave me the impression of something built around feature demonstration rather than operational design. There was extensive use of emojis and decorative UI elements throughout the application. For a consumer application, that might be harmless. For a system intended to handle school administration, students, staff, payments, subscriptions, and financial records, it communicates a strange lack of product maturity.

The problem is not that emojis are inherently bad. The problem is context.

A school administrator does not need another visually noisy dashboard trying to make administrative software feel exciting. They need to perform repetitive operational tasks quickly and reliably. The interface should make important information obvious, reduce cognitive overhead, and help staff get through routine work without constantly maintaining another layer of software.

The product also appeared heavily centered around CRUD-style workflows. There were plenty of mechanisms for creating, editing, activating, configuring, and viewing records, but much less that convinced me the system was actually eliminating work from a school's existing administrative processes.

That distinction matters. A school-management system is valuable when it connects workflows so that one action eliminates several others. A payment should reconcile itself. An attendance record should feed reporting and communication. A student record should not require the same information to be entered repeatedly in different places.

Instead, VoraFly often felt like it was providing another place to store and manipulate information. That was my product assessment before I even started looking for security problems. The security testing simply made the impression worse.

Account Creation Was Already Too Trusting

The first thing I noticed was how little assurance was required to begin using the application.

I created an account using a synthetic email address. There was no email verification step encountered during the workflow, and I was able to access the application's financial functionality without first proving ownership of the email address.

I also encountered no KYC or organizational verification requirement before reaching the relevant financial workflows.

That does not prove there is no verification mechanism anywhere in the entire product. It does show that the tested onboarding path did not require meaningful identity assurance before exposing functionality with financial consequences.

A school-management platform can reasonably allow someone to create a trial account. It becomes much more concerning when that same account can immediately interact with a wallet and initiate large-value payment flows.

The Password Strength Meter Was Backwards

The password-strength indicator provided another early warning sign.

I tested Pass2026, and the application classified it as Strong. I then added a dollar sign, producing Pass2026$, and the application classified it as Weak. Adding more dollar signs did not restore the password to strong. Removing the dollar signs returned the original password to Strong.

In other words, the application was effectively communicating that a predictable word-plus-year password was stronger than the same password with additional special characters.

This was not the most serious vulnerability I found, but it was revealing. A password-strength meter is itself a security control. It is supposed to help users choose stronger credentials. Here, the control was giving misleading advice.

The Wallet Claimed a ₦10 Million Maximum

The wallet funding interface stated that the minimum was ₦100 and the maximum was ₦10,000,000.

I tested whether that maximum was actually enforced. It wasn't.

The interface accepted an absurdly large numeric value and passed it downstream. Flutterwave subsequently displayed the amount as NGN 1e+72 and rejected the transaction because the amount exceeded its own limit.

That distinction is important. The application's advertised ₦10 million maximum was not what stopped the transaction. Flutterwave's own limit stopped it.

The application therefore had a business rule in its UI that was not actually protecting the payment boundary. This was my first clear indication that the application was relying on downstream behavior to enforce constraints that should have been enforced by the application itself.

Then I Found the Payment Environment Problem

This was where the assessment changed completely.

The Flutterwave checkout I reached was clearly operating in test mode. Flutterwave documents its test and production environments as separate environments, with test transactions mocked and stored separately from production. Test mode is intended for simulated transactions, not actual financial processing.

That immediately raised an obvious question: why was a production VoraFly application sending me to a Flutterwave test environment?

Figure 0. VoraFly's Checkout Page

I decided to test the boundary rather than assume it was merely a configuration mistake.

I used Flutterwave's published sandbox test credentials and performed a controlled ₦7,000,000 transaction. The Flutterwave test checkout reported the transaction as successful.

I returned to the VoraFly application. The production wallet showed ₦7,000,000.

This was not merely an amount displayed on the checkout page. The wallet showed the balance as internal application state, including a credit transaction, a resulting balance, and a wallet transaction described as a Flutterwave top-up.

A mocked payment event had crossed the boundary into the production application's financial state. That was the major discovery.

The Balance Was Not Merely Cosmetic

At this point, it would have been possible to argue that the application had simply displayed the wrong balance. I therefore tested whether the balance actually had authority inside the application. It actually did.

The application offered a premium plan with a ₦50,000 term fee. I activated it using the wallet balance.

The wallet went from ₦7,000,000 to ₦6,950,000, and the first term became active. The school was subsequently shown as fully activated.

Figure 1. Wallet Dashboard

This was the point where the severity became much clearer. The sandbox-derived balance was not a cosmetic artifact. The production billing system trusted it.

The application's internal economic model had accepted a payment that Flutterwave itself considered a test transaction.

Flutterwave's payment documentation recommends verifying a transaction before granting value, including checking the transaction reference, status, currency, and amount.

The intended trust boundary should therefore look something like this:

Flutterwave transaction
        ↓
Verify transaction
        ↓
Confirm production transaction
        ↓
Credit production wallet
        ↓
Grant production entitlement

What I observed behaved more like this:

Flutterwave test transaction
        ↓
Production wallet
        ↓
Production entitlement

That is not a small configuration detail. It is a failure of the application's financial trust boundary.

The Problem Was Reproducible

I did not want to base the case study on one account, so I created another school through the referral flow.

This time the newly created organization was called Vibecoder Schools. Its wallet initially contained ₦0.

I then performed another controlled Flutterwave sandbox transaction. The resulting VoraFly production wallet balance was ₦7,299,999.

Again, the value appeared in the production application. Again, the application treated it as usable wallet balance. Again, I used that balance to activate the paid functionality, resulting in a ₦50,000 deduction and a remaining balance of ₦7,249,999.

Figure 2. Vibecoder School's dashboard

This mattered because it eliminated the possibility that the first incident was simply an unusual state associated with one particular account. The behavior was reproducible across independently created organizations.

I had now demonstrated the same fundamental payment-environment failure twice.

The Audit Trail Did Not Reflect the Payment

VoraFly's audit-log interface describes itself as a tamper-resistant history of sensitive actions and explicitly mentions payments among the events it records.

After performing the wallet funding and subsequent activation, I could not find the corresponding payment event in the application's audit-log interface. The interface showed other events, including plan-related activity, but the wallet payment itself was absent from the audit-log view I inspected.

Figure 3. Audit logs

I am deliberately precise here. I am not claiming that the payment is necessarily absent from every backend database or internal logging system. The finding is that the payment event was not visible in the application's purported audit-log interface, despite the interface describing payments as auditable events.

For a financial workflow, that matters because incident response eventually depends on being able to reconstruct what happened. If a company needs to determine which payment produced a wallet credit, which wallet funded a subscription, which subscription generated a referral, and whether the original payment was actually valid, those relationships need to be reliably auditable.

A partial audit trail makes that reconstruction much harder.

Then I Looked at the Partner Program

The partner system advertised a 20% commission and fast payouts.

I created a partner account using clearly synthetic information. The account was accepted and the partner dashboard provided a referral code.

The partner profile showed the account as PENDING and UNVERIFIED, yet the system had already provisioned a partner ID, referral code, 20% commission rate, and referral dashboard.

The important point is not simply that the partner account existed. It is that an account explicitly marked UNVERIFIED had already been given functional referral infrastructure tied to an economic incentive.

Figure 4. Referral Partner Dashboard

There was no meaningful KYC process encountered during this workflow.

Again, I am not claiming that VoraFly has absolutely no verification mechanism anywhere. I am saying that the tested partner onboarding flow accepted synthetic information and still provisioned the referral machinery.

That is a poor trust boundary for a program whose purpose is to create financial liabilities to third parties.

The Referral Link Was Wrong

The partner dashboard generated a referral URL on the partner subdomain:

https://partner.vorafly.com.ng/r/vora-9kvrpl

Clicking the generated URL did not take a prospective school to the school-registration process. It led back to the partner site.

At first, the referral system looked broken. Then I changed only the hostname:

https://vorafly.com.ng/r/vora-9kvrpl

That worked. The school registration page displayed “Referred by Slop Vibecoder.”

This was an interesting distinction. The underlying referral mechanism was functional, but the URL generator was producing the wrong URL.

A technical user can inspect the link, notice the domain mismatch, manually correct it, and continue. An ordinary partner is unlikely to do that. They click the link VoraFly tells them to share, see the wrong page, and reasonably conclude that their referral link does not work.

For a company actively using partner referrals as a growth channel, that is not merely a cosmetic defect. It directly interferes with the acquisition mechanism being marketed to partners.

The Referral Attribution Actually Worked

Once I corrected the hostname, the referral system began behaving normally.

I created the referred school and then checked the partner dashboard. It now showed one click and one registration, while the newly created school was correctly attributed to the partner.

This established a working relationship between the partner system and the school-management application. The referral code was not simply displayed by the registration page as decoration. The registration event propagated back into the partner dashboard.

That made the referral system considerably more interesting from a security perspective, because there was now a real economic relationship connecting the partner and school systems.

The Sandbox Payment Crossed Into the Referred School Too

The referred school was a completely separate organization, so I repeated the payment test.

Its production wallet received ₦7,299,999 from the Flutterwave sandbox transaction. I then activated the paid subscription, which consumed ₦50,000 from that balance.

The sequence was now reproducible through a referral-created organization:

Synthetic partner
        ↓
Referral code
        ↓
School registration
        ↓
Independent school account
        ↓
Flutterwave sandbox payment
        ↓
Production wallet credit
        ↓
Production subscription activation

At this point, I had already demonstrated enough to establish that the payment environment problem was systemic rather than an isolated account anomaly. Then, the referral system provided the final piece.

And Then the Commission Appeared

After the referred school was activated, I checked the partner's earnings dashboard.

It showed the school, the ₦50,000 activation, the 20% commission rate, and a ₦10,000 commission marked PENDING. The partner dashboard showed ₦10,000 in total earned and ₦10,000 pending, with nothing yet available or paid out.

Figure 5. Referral Earnings

This distinction matters because I did not demonstrate an actual cash payout. I demonstrated that the application had generated a commission liability. 

The corrupted financial state had propagated into another business subsystem.

The complete chain was now:

Flutterwave sandbox payment
             ↓
Production wallet credit
             ↓
Production subscription activation
             ↓
Referral attribution
             ↓
20% commission calculation
             ↓
₦10,000 pending commission

At this point, calling this merely a payment integration bug would undersell what was happening. A payment-environment failure was contaminating the application's internal economic model.

Why This Becomes a Business Problem

The obvious reaction to a bug like this is that someone could get free money. That is not actually the most interesting problem.

The sandbox money itself is not real money. Flutterwave explicitly describes its test environment as mocked and separate from production, with no actual transaction processing taking place.

The deeper problem is that VoraFly was converting a non-production event into trusted production state.

Once that happens, everything downstream can trust the contaminated state. A wallet balance can become a subscription, a subscription can become an activation, an activation can become a referral event, and a referral event can become a commission.

That is an economic state machine. If the first state is invalid, every subsequent state needs to be treated as suspect.

The Abuse Scenarios Are Bigger Than the Initial Bug

I stopped after demonstrating the complete chain. I did not attempt to scale the behavior, withdraw commissions, or cause financial loss.

However, the demonstrated primitives are enough to describe several plausible abuse scenarios.

An attacker could potentially populate the application with synthetic school organizations, particularly if account and organization creation remain weakly verified. That would pollute the platform's customer database and make genuine customer analytics less trustworthy.

The referral program introduces another layer. A malicious partner could potentially create or recruit synthetic organizations through a referral relationship, while the partner system records registrations and activations as legitimate application events.

The most interesting scenario, however, is commission-liability accumulation. An attacker would not necessarily need to attempt an immediate payout. If invalid transactions can produce valid-looking activations and commissions, those commissions could potentially remain pending while appearing to be legitimate historical activity.

That creates a reconciliation problem.

Imagine the platform later contains hundreds of genuine schools, genuine payments, genuine activations, and genuine referral commissions alongside records that ultimately originated from test transactions. The company would then need to determine which internal financial states came from actual production payments and which originated from invalid payment events.

That becomes substantially harder if the records have already propagated through several systems.

The Commission Dispute Problem

There is an especially uncomfortable scenario here.

Imagine a malicious partner creates a large number of apparently valid referrals and allows the resulting commissions to accumulate. Months later, when the company is operating at a much larger scale, the partner requests payout.

The partner can point to VoraFly's own records and say: you recorded these schools, you recorded their activations, you calculated my commission, and you marked those commissions as pending. Why are you refusing to pay me?

VoraFly would then need to reconstruct the provenance of every disputed commission.

For each one, it would need to establish a trustworthy chain from commission to activation, from activation to wallet debit, from wallet debit to wallet credit, and from wallet credit to a verified production payment.

If the original payment state cannot be trusted, the company has a dispute involving its own accounting records.

This is precisely why payment verification needs to happen before value is granted, rather than being treated as a cleanup problem later. Flutterwave's documentation recommends verifying the transaction reference, status, currency, and amount before granting value.

The application needs to establish that a transaction is valid before allowing it into the internal economic system. Not afterwards.

The Bigger Engineering Failure

Looking at the individual findings is useful, but looking at them together is more revealing.

The application repeatedly demonstrated a pattern where the happy path worked while the boundaries around that happy path did not.

The UI could collect a payment, but the environment boundary was wrong. The wallet could hold money, but the source of that money was not sufficiently trusted. The subscription could activate, but it trusted the wallet state. The referral system could track registrations, but the generated URL used the wrong hostname. The partner system could calculate commissions, but the underlying economic event could originate from a sandbox payment. The audit system claimed to record payments, but the payment event was not visible in the audit-log interface I inspected. The password system could rate passwords, but its rating logic was nonsensical. The application could display a maximum transaction amount, but the limit was not enforced before the value reached the payment provider.

These are different bugs, but they point toward the same engineering problem.

The system appeared to care much more about whether a workflow could happen than whether it was actually allowed to happen.

This Is What I Mean by Vibecode

I want to be careful here because I cannot prove that VoraFly was written by an LLM. I did not inspect its source repository, development history, prompts, or engineering process.

My conclusion is about the characteristics of the resulting product.

VoraFly exhibits many of the characteristics I associate with vibecoded software that has been pushed too far into production.

The screens exist. The buttons work. The APIs appear to connect. The dashboards are there. The payment page is there. The referral system is there. The subscription system is there. But, the relationships between those systems have not been treated with the same level of engineering discipline.

A competent application is not merely a collection of working features. It is a collection of invariants.

For a payment system, one such invariant should be that a production wallet can only be credited by a verified production transaction.

For a subscription system, a subscription should only consume a valid production balance.

For a commission system, a commission should only be generated from a legitimate qualifying production transaction.

For an audit system, a financial state change should produce an auditable record.

For an identity system, financially consequential privileges should require an appropriate level of identity assurance.

These are not exotic requirements. They are the basic rules that keep the system coherent.

The Illusion of Competence

This is where I think the VoraFly case becomes bigger than VoraFly.

One of the most interesting consequences of modern LLM-assisted development is that the barrier to producing software that looks finished has fallen dramatically.

That is an incredible development when used correctly. It allows people to prototype ideas that previously required substantial engineering resources, and it can make experienced developers dramatically more productive.

The problem begins when the ability to generate software is mistaken for the ability to engineer software.

An LLM can generate a dashboard. It can generate authentication, a database schema, a payment form, a referral system, a subscription system, and APIs connecting all of them. If the person directing it does not understand the underlying systems deeply enough, however, they can end up with something that looks far more complete than their own understanding of the system.

That is the illusion of competence.

The founder sees the landing page, dashboard, payment integration, subscription system, referral program, analytics, and production deployment and concludes that they have built a startup.

But software is not a checklist of screens. The difficult part is understanding what must never be allowed to happen.

A person who does not understand payment architecture can now generate a payment integration. A person who does not understand authentication can generate login screens. A person who does not understand accounting can generate wallets and transaction tables. A person who does not understand distributed systems can generate webhook handlers. A person who does not understand security boundaries can deploy all of it.

The resulting application may look convincing enough to attract customers. This is the dangerous part.

Research published in 2026 is increasingly documenting this distinction. A systematic study of real-world vibe-coded applications found recurring security problems and attributed them in part to limitations such as locally optimized objectives, insufficient security knowledge, and other weaknesses in the AI-assisted development lifecycle. Another study evaluating coding agents on realistic software tasks found that functional correctness and security did not necessarily move together: some generated solutions could perform the requested task while still failing security evaluation.

In other words, the problem is not simply that an LLM occasionally writes a bad line of code. It can produce a sufficiently convincing amount of software to allow someone to cross into territory they are not yet competent enough to operate safely.

The Dangerous Part of Vibecoding Is Not That AI Writes Bad Code

I think that criticism is too shallow.

The more interesting problem is that AI makes it possible to create something that looks much more complete than the builder's understanding of the underlying system.

That changes the relationship between competence and output.

Historically, there was a fairly obvious friction point. If you did not know how to build something, you eventually reached a point where you could not build it.

LLMs remove a large part of that friction. That is their power. It is also their danger.

The ability to generate a working payment integration does not mean the person generating it understands payment verification. The ability to generate an authentication system does not mean they understand identity assurance. The ability to create a financial dashboard does not mean they understand accounting invariants.

The code can now outrun the builder's understanding.

That is why I find the phrase illusion of competence more useful than simply saying that AI produces insecure code.

The LLM can make an inexperienced person feel like an experienced engineer because the immediate feedback loop is so convincing. Prompt something, get a feature, run it, see a dashboard, fix an error, add another feature, deploy it, and suddenly there is a functioning application sitting on the internet.

The difficult part is that the application may be functioning while its creator still does not understand why it is safe.

That distinction becomes especially dangerous when the software handles money, identity, healthcare, education, legal records, or any other domain where correctness is more important than whether the interface appears to work.

The GTM Problem

What makes this case even more concerning is the timing.

VoraFly was already doing go-to-market. It was recruiting partners, advertising commissions, and encouraging people to refer schools.

The application was therefore not merely being developed in isolation. Its economic incentives were already being exposed to strangers. That creates a dangerous mismatch between go-to-market maturity and engineering maturity.

A company can build a referral program extremely quickly with modern AI tools. It can generate the landing page, partner dashboard, registration flow, commission calculation, and marketing copy in a fraction of the time that conventional product development would have required.

But that does not mean the company has established the controls necessary to operate that system safely.

You do not want your growth engine to become an amplifier for an untested trust boundary.

The more successful the referral program becomes, the more attractive the underlying economic system becomes to someone looking for abuse.

The irony is that the same mechanism intended to accelerate growth can accelerate exploitation.

What I Would Fix First

If I were responsible for remediating the application, I would not start by redesigning the dashboard.

I would start with the financial trust boundary.

The first priority would be to completely separate test and production payment environments. Test credentials, webhook configurations, secrets, callback handling, and payment records should never be allowed to cross into production state accidentally. Environment isolation is a fundamental security practice precisely because development and test data should not be trusted as production state.

The second priority would be payment verification. A production wallet should only be credited after the backend independently verifies the transaction with the payment provider and confirms the expected transaction reference, status, currency, amount, and production environment.

The third would be enforcing monetary limits on the backend. If the business rule says the wallet maximum is ₦10 million, the server should reject anything above that amount before the value is sent downstream.

The wallet itself should then be treated as a proper financial ledger rather than merely a number attached to an account. Every credit should have a source, provider, transaction reference, environment, amount, currency, timestamp, verification result, account, and resulting balance.

The commission system should similarly be tied to verified production transactions rather than merely to the existence of an internal subscription activation. An activation should ultimately be traceable to a qualifying production payment.

Identity assurance should also be addressed. If a company wants to pay partners, it needs to know who those partners are. The exact KYC requirements can vary by business model, but an explicitly unverified partner should not casually receive a fully functioning revenue-generating referral identity.

The referral URL generator needs to be fixed as well. The system already knows how to attribute the referral correctly; it simply needs to generate the correct URL in the first place.

Finally, financial events need a coherent and trustworthy audit trail. Payments, wallet credits, subscription activations, reversals, and commission calculations should be traceable through a consistent chain of records.

Most importantly, the test strategy needs to change. The application should not merely be tested for whether the happy path works. It should be tested for whether the business invariants survive hostile conditions.

Can a test transaction credit production? Can a failed transaction activate a subscription? Can an unverified partner accumulate commissions? Can a wallet credit exist without a verified payment? Can a commission exist without a qualifying production transaction? Can an amount larger than the business maximum reach the payment layer?

Those questions are much more valuable than another round of testing whether the “Pay” button opens the checkout page.

What I Actually Demonstrated

I want to separate demonstrated facts from hypothetical impact.

I demonstrated that I could create school accounts using synthetic information and reach financial functionality without encountering meaningful email verification. I demonstrated that the wallet's advertised maximum was not enforced before the payment provider and that an extremely large amount was propagated downstream as scientific notation.

I demonstrated that the Flutterwave checkout exposed by the production application was operating in test mode, and that a successful sandbox transaction resulted in a production VoraFly wallet credit.

I demonstrated that the resulting balance was accepted by production billing logic and could be consumed to activate a paid subscription.

I reproduced the payment-environment failure on a second independently created school.

I demonstrated that a synthetic partner account could be created while remaining marked unverified, that the partner received a referral code and 20% commission configuration, and that the referral attribution worked after correcting the hostname in the generated referral URL.

I demonstrated that the referred school could independently receive sandbox-derived production wallet value and use it to activate a paid subscription.

Finally, I demonstrated that the resulting activation generated a ₦10,000 pending referral commission.

I did not demonstrate an actual commission cash payout. I did not attempt to withdraw the commission, scale the behavior to hundreds of organizations, or cause financial loss. I stopped after establishing the complete chain.

I did not need to go further. The important security boundary had already failed.

Final Thoughts

I started this assessment thinking: This looks like vibecoded slop.

That was a subjective judgment based on the UI and the product experience. After testing it, I came away with a more specific conclusion.

The problem was not simply that the application looked like it had been built quickly. The problem was that the engineering appeared to have stopped at the point where the happy path worked.

The application could display a wallet. It could fund the wallet. It could activate a subscription. It could calculate a commission. It could show an audit log. It could run a referral program.

Everything looked like it worked. But, when I tested the boundaries between those systems, the assumptions started falling apart.

The payment flow is the clearest example. Flutterwave's test environment is explicitly designed for simulated transactions, with test data separated from production. Its documentation also recommends verifying transactions before granting value.

Yet a mocked transaction was able to become production wallet value inside VoraFly. That wallet value then became a production entitlement. That entitlement then became a referral commission.

At that point, the issue was no longer simply that someone had configured Flutterwave incorrectly.

It was a failure to understand the concept of a trust boundary. And, that is where my broader concern about vibecoding comes in.

AI-assisted development is not inherently bad. In fact, it is extraordinarily powerful. Experienced engineers can use these tools to move faster, explore ideas more cheaply, and build things that would previously have required substantially more time.

The problem begins when the speed of generating software is mistaken for the acquisition of engineering competence.

An LLM can help someone build an impressive prototype without teaching them why that prototype is safe. It can make the screens look finished before the architecture is mature. It can make the workflow feel complete before the business invariants have been defined. It can make the founder feel like they have become a technical organization before they have developed the ability to reason about the system they just deployed.

That is the illusion of competence.

And startups are particularly vulnerable to it because startups reward speed. Launch the landing page. Ship the dashboard. Add payments. Recruit partners. Start GTM. Get customers.

The software can appear to keep up with the business. Until someone asks a question the original builder never asked.

In this case, the question was simple:

What happens if the payment provider says this is a test transaction?

The application had an answer. It credited the production wallet.

That is what concerns me most about the current wave of vibecoding. The danger is not simply that an LLM might produce an insecure line of code. The more fundamental danger is that it can produce enough convincing software to allow someone to operate a system whose complexity they do not yet understand.

The prototype can become convincing long before the engineer becomes competent enough to know where the prototype ends and production begins.

VoraFly is a particularly useful example of that problem because the failures did not require exotic exploitation. They emerged from ordinary workflows: account creation, payment, wallet funding, subscription activation, referral attribution, and commission calculation.

The individual screens worked. The system did not. 

Exactly, this distinction is the entire point.