Latest Posts

Stay in Touch With Us

Got a story worth telling? Send it our way. We read every tip that lands in our inbox.

Livebriefs

  /  All News   /  ‘Insight, taste, and distribution’: How to turn vibe-coded apps into cash

‘Insight, taste, and distribution’: How to turn vibe-coded apps into cash

Vibe coding makes developing an app as simple as describing your idea. With barriers collapsed, it is easy to assume that app monetization is dead.

Stan Marchand disagrees. As CEO of Paris-based app publisher Rocapine, he has proved that vibe-coded apps can still generate real revenue – but only if builders focus on the 20% of app development that moves beyond the code and into human craft.

I spoke with Stan to unpack what separates a buyable product from an empty gimmick in 2026.

Vibe coding has made it easier than ever to build apps, but are these apps actually generating revenue?

Building is now the easy part. The scarce skills are insight, taste, and distribution.

A few are, but most aren’t, and most often it’s because people assume building a functioning app is the hard part. It isn’t anymore.

Vibe coding has collapsed the cost of building an app to almost nothing. But 80% of the work can now be automated, and more than ever it’s the remaining 20% left to humans that decides whether an app makes money: finding a value proposition that genuinely resonates, crafting a product with human taste, and telling its story efficiently.

The apps generating real revenue got those three things right. The flood of apps that look finished but never find a market got none of them. Building is now the easy part. The scarce skills are insight, taste, and distribution.

When assessing a vibe-coded MVP, which metrics and signals do you look for to separate a “buyable” app from a gimmick?

The code itself is not worth much.

What is worth something is whether the product resonates with real people. That is shown by asking two questions:

  • Is it marketable? Can you reach users at a cost the business can support, or is the market already saturated by giants pushing the same promise?
  • Will people pay? Once they’ve installed it, do they convert and stick? The KPIs that capture this are cost per install, conversion to paid, and early retention.

Put these questions together: that’s ROAS- how much it costs to acquire a user versus how much that user is worth.

A rough prototype with a low cost per install and users who pay is a real business. A polished app with beautiful code and no one converting is a gimmick.

How does that evaluation process differ when assessing vibe-coded apps compared to traditional human-built apps?

We evaluate the 20% the builder added: the insight, the craft, the taste.

Less than you’d think.

Nobody writes code by hand anymore, so “vibe-coded” versus “human-built” is becoming a distinction without a difference.

What changes is where we spend our time. With vibe-coded apps, the code is cheap to rebuild, so we care less about its quality and more about whether the concept has proven resonance.

The risk isn’t messy code, it’s a product that exists because it was easy to make rather than because anyone needed it. AI gives everyone the same 80%. We evaluate the 20% the builder added: the insight, the craft, the taste.

AI-generated code can be messy. What steps must vibe coders take to ensure their app is legally compliant and structurally sound enough to pass due diligence?

Three things:

  • Know your stack: which tools generated what, under which licenses, and whether any third-party code or assets carry restrictions. Undocumented AI code isn’t a dealbreaker; undocumentable code is.
  • Clean data practices from day one: privacy policy, user consent, App Store and Play compliance, and analytics you can actually export.
  • Make your metrics verifiable: revenue through the stores, retention cohorts, acquisition costs. We’ve walked away from partnerships not because the code was AI-generated, but because nothing could be checked.

How should an app creator think about deciding whether a full acquisition, a publishing deal, or a revenue-share model is right for them?

Ask yourself what you actually want.

If you want the cash and to move on to the next idea, a full acquisition is clean. If you believe in the app and want to stay in the game, a publishing or revenue-share deal lets you keep upside while a partner brings what a solo builder rarely has: monetisation expertise, growth marketing budget, the infrastructure to scale.

The good news is that these paths aren’t mutually exclusive. Unchaind, which we co-developed from scratch with a studio in Singapore under a publishing model, reached $1M ARR 16 days after launch. We ended up acquiring it later, once the developer wanted to move on to a new project.

Start with the model that fits where you are today; the exit can come when it makes sense for both sides.

What other tips would you give keen vibe coders who are looking to build and sell vibe-coded apps?

Fight AI slop relentlessly

Build for a niche you understand deeply, ship in weeks, and put a price on it immediately. Free users tell you nothing about resonance.

Then fight AI slop relentlessly: the generic wording, the template design patterns, the onboarding everyone recognises. Users spot it instantly, and it kills trust. Invest your time in the 20% that makes your product yours; the rest is a commodity.

And when you talk to a publisher, bring your cohort data, not your feature list.

​  

You don't have permission to register