At RevenueCat we’ve seen a strong trend in first-time developers shipping apps and making their first dollars using vibe coding tools. The trend is clearly visible in number of developers making their first API call:
To understand this new wave of developers, we decided to become them.
Making everyone a customer
At the end of last year we kicked off an internal hackathon, titled Vibeathon, here at RevenueCat. The idea was simple: get everyone in the company to build apps using the same tools our customers are using. This included tools such as Vibecode, Rork, Claude, Cursor, and other agentic development tools — tools that allow non-engineers to build software.
Shipping quickly and often is one of the core values at RevenueCat, so we gave everyone until the end of January to build an app, add the RevenueCat SDK, and ship it to app stores. Out of the full RevenueCat company, 44 signed up for the hackathon, close to 30 apps got built, and 12 made it to app stores in time. The best part was that most people were from non-engineering functions.
Learning through building
Unsurprisingly, people ended up solving their own problems: building apps to track golf progress, recognize good firewood, scan receipts for taxes, and get book suggestions. Our hackathon showed the democratizing effect of vibe coding in microscale: cheaper build process makes it easier to target underserved niches.
Before publishing this article I took a look at how much money the built apps have made, and at the moment these apps sit at a bit over $700 in revenue since the beginning of the year. Not enough for anyone to retire, but enough to signal that we built things people found valuable. Comparatively, the two batches of Shipathon (2024 and 2025) have collectively made over $5.5 million, so our apps have some catching up to do still.
Fast to build, hard to understand
The focus of this hackathon was learning, and we ended up learning about our product, customers, and the vibe coding movement more than we could have expected.
During the Vibeathon people were building fast and iterating quicker, but a lot of people emphasized how little they actually gained understanding in what was being built. Apps ended up being blackboxes that rely on AI to make improvements. When Apple would reject the app because of a bug, the participants could not diagnose the problem themselves, but had to go back to the AI and hope that it could fix it. Vibecoders are not authors of the product, but operators.
Some participants wanted a more structured approach and created SPEC.md and AGENTS.md to describe how agents should approach the tasks and what patterns to avoid. After that Codex was capable of one-shotting the app during dinner time, signalling that skill in vibecoding is not prompting, but specification writing. Good spec of course requires good understanding of the development concepts that the agent needs to follow. Essentially you’re aiming at getting a good output from a junior developer.
Most apps were built with React Native (with few Swift exceptions), and all but one targeted iOS. This was also the only platform most of the vibe coding tools support, despite React Native being a cross-platform framework.
The App Store was the hard part
Vibeathon brought in a lot of people who had not previously built apps, or had maybe built an app a decade ago and not touched App Store Connect or Play Store Console after that. For most people it turned out that building the app is the actual easy part, and getting it approved through Apple’s and Google’s reviews is the hard part.
This could be called the last mile problem of vibe coding, when code and implementation become cheaper and more approachable by masses, the real moat is in turning those things into apps and services that users can actually download.
People also struggled with setting up accounts, in some cases it taking Apple a few weeks to ensure that all required documentation was in order to deploy an app. The contrast is huge, when building an app can take just 5 minutes, but becoming able to distribute can take weeks. This is one of the topics we plan to focus on in the new StartApp School program, by providing detailed guidance on how to set up your Apple and Google Developer accounts.
Monetizing remains a big hurdle as well. Adding RevenueCat SDK is easy, but Apple and Google have both made it very difficult to be compliant with all their in-app purchases rulings on the first try. Almost no app got through the review process the first submission, and most people reported the constant back and forth between fixing reported issues, to end up just getting new ones.
Make your people code
Even before we kicked off Vibeathon, RevenueCat was working on better support for different vibecoding tools. Last year we released our MCP, which allows you to setup and manage products in RevenueCat and App Store Connect through agents. We’ve since improved the MCP with more features, and improved the support for it in different vibe coding tools. RevenueCat dashboard also now supports more agent friendly setup flow, giving you the prompts to setup the SDK without having to do it yourself.
Vibeathon was the first time we forced people to work solo on these projects. The promise of vibecoding being that anyone from sales to marketing, and operations to engineering could build and monetize apps, without spending considerable time on learning how to code, or having previous technical experience. Understanding this is important as it is being embodied in our new customers as well, who are building apps with a similar setup: no technical background.