Case Studies

From Idea to Both App Stores in 48 Hours: What Vibe Coding Actually Shipped

Focused developer at night building a mobile app with glowing ring interfaces visible on a laptop and phone

Here is the short version: at an internal 24-hour hackathon this month, one of our developers took a medication tracker from first prompt to store-ready builds in 17 working hours using Claude Code, and roughly 48 hours after the idea existed, PotionKeep was live on both the Apple App Store and Google Play. One hundred downloads followed in two weeks before we spent a single dollar on marketing.

This post is the honest teardown: what the AI actually did, what the human actually did, the one rejection we hit, and what a stunt like this does and does not prove about shipping real products.

Why Did We Run This Experiment?

The timing was deliberate. Anthropic had just made its newest model, Claude Fable 5, available in Claude Code, and we wanted a real answer to a question every studio is asking: how much of a genuine product cycle can AI-assisted development actually absorb? Not a demo, not a to-do list app that dies in a repo: a product with a store listing, an in-app purchase, and strangers downloading it.

So we set hackathon rules that would make the answer unambiguous. One developer. One 24-hour window. The app had to reach both stores, monetization included. And it had to be something we would genuinely use.

The idea we picked: a medication and supplement tracker that does not feel like homework. Meds, vitamins, and even coffee become "spells" with an onset, duration, and cooldown. Log a dose and a glowing ring counts down through charging, active, and cooldown, so you always know what is active and when it is safe to take more. Serious tracking, disguised as a game. We called it PotionKeep.

What Happened in the 24-Hour Window?

Hours 0 to 12, day one. The core app went from empty Flutter project to working product: the ring engine that animates each buff through its states, one-tap dose logging with backdating, the spell library where you define onset and duration, and the feature that would have been unthinkable in a one-day scope before AI assistance: three complete visual themes. Fantasy, with a warm spellbook feel, free for everyone; a neon Sci-Fi reactor; and a calm Minimal skin, the latter two behind a Pro purchase. Same dashboard, three identities, switchable at any time.

Hours 12 to 17, day two. Polish, app icons, store screenshots, listing copy, privacy declarations, and submission to both stores before the window expired. Total hands-on time: about 17 hours.

Two decisions made that speed possible, and both were human decisions, not AI output. First, local-first everything: no account, no cloud, no analytics. That is PotionKeep's privacy stance, and it also deleted an entire backend from the scope. Second, ruthless cuts: no social features, no streak mechanics, no wearable integration. A 24-hour product is defined by what you refuse to build.

Where Did It Go Wrong? The Apple Rejection

Google Play approved the build. Apple bounced it, and the reason is instructive precisely because it is boring: we had not configured the Pro in-app purchase in App Store Connect. The code was fine. The app was fine. The listing referenced a purchase that did not exist as a product in Apple's system, because in the sprint to beat the clock, a console configuration step got skipped.

We added the IAP product, resubmitted, and Apple approved within hours. Total damage: one review round-trip.

If you have read our Meta Quest Store submission guide, this will sound familiar: across every store we ship to, rejections almost never come from code quality. They come from process: missing metadata, unconfigured products, unchecked boxes in a console. AI collapsed the build time, and the submission checklist stayed exactly as human as it has always been.

What Did the AI Actually Do, and What Did the Human Do?

The honest division of labor, because this is the part most vibe-coding stories blur:

Claude Code produced the bulk of the Flutter implementation: the state machine behind the rings, the theming architecture that made three skins cheap, layout code, animations, and the refactors along the way. When the developer described a behavior, working code appeared in minutes, and the loop of describe, run, correct stayed fast for all 17 hours.

The developer decided everything that made it a product rather than a codebase: the buff metaphor, the local-first privacy stance, what Pro includes, every scope cut, when generated code was good enough versus when it needed to be rejected and redirected, and the entire store-submission process, including the IAP lesson above. The developer also reviewed what shipped: vibe coding without code review is how you ship someone else's bug under your company name.

That ratio, AI writing most of the code while a human makes every decision that matters, is what 17 hours to store-ready actually looked like. Drop the human judgment and you do not get a slower version of the same result; you get no result.

What Does This Prove, and What Doesn't It?

It does not prove that enterprise software now takes a weekend. PotionKeep has no integrations, no stakeholders, no compliance review, and a scope chosen specifically to fit the window. Our client work in enterprise VR training and beyond involves everything this hackathon deliberately excluded, and none of that disappeared.

What it proves is where the floor moved. The weeks a project used to spend on scaffolding, UI iteration, and boilerplate now compress into hours, which changes what a prototype budget buys and how fast an idea can meet real users. Since the hackathon, the same AI-assisted workflow has been folded into how we scope client prototypes and MVPs: the saved hours go into discovery, design, and on-device testing, the parts that still require humans and always will.

PotionKeep, meanwhile, is a real product with a real roadmap: it is live on the App Store and Google Play, the full case study is on our PotionKeep project page, and the growth phase, site SEO and social, starts now. One footnote for clarity: PotionKeep tracks what you log and when it clears; it is a tracking tool, not medical advice.

If you have an idea that deserves the same treatment, from 48-hour proof-of-concept to production build, talk to us. We will tell you honestly which parts take hours now, and which parts still take the time they always did.

Frequently asked questions

What is vibe coding?
Vibe coding is AI-assisted development where you describe what you want in natural language and an AI coding agent writes, runs, and revises the code, while you steer product decisions, review output, and keep or reject what it produces. In our hackathon, that meant one developer directing Claude Code through a full Flutter app: the developer owned the product decisions and code review, and the agent produced the bulk of the implementation.
Can AI-generated code really ship to the App Store and Google Play?
Yes, and ours did: PotionKeep was approved on both stores roughly 48 hours after the first prompt. The caveat is that store review does not care how the code was written; it cares about guidelines. Our only rejection was a human process miss (an in-app purchase not configured in App Store Connect), not a code-quality issue. AI can write the app; a human still has to know the submission checklist.
How long did the PotionKeep build actually take?
About 17 hands-on hours inside a 24-hour internal hackathon window: 12 hours on day one for the core app (ring engine, dose logging, spell library, three-theme system) and 5 hours on day two for polish, store assets, and both submissions. Store review added the rest of the elapsed time, and the app was live on both stores about 48 hours after the idea.
What stack was PotionKeep built with?
Flutter and Dart, one codebase for both iOS and Android, written in a Claude Code session running Anthropic's Claude Fable 5 model. Data is local-first on the device with no backend, no account, and no analytics, which was both a privacy decision and a scope decision: no backend meant nothing server-side to build, secure, or maintain inside 24 hours.
Does a 24-hour hackathon app prove anything about real client projects?
Directly, no: a hackathon app skips stakeholder alignment, integration work, and compliance review that enterprise projects require. What it proves is where the floor is now. Scaffolding, UI iteration, and boilerplate that used to consume the first weeks of a project now take hours, which changes what a prototype budget buys. We now use the same AI-assisted workflow to accelerate client MVPs, with the saved time reinvested in the parts AI cannot do: discovery, design judgment, and testing on real devices.
Vibe Coding AI-Assisted Development Claude Code Flutter App Store Hackathon
Mohamed Essam
Mohamed Essam
Co-Founder & CTO

Co-founder and CTO of Virtual Verse Studio. Leads technical direction and client delivery, with deep hands-on expertise in Unity, Unreal Engine, AR/VR, multiplayer systems, and XR architecture — shipping immersive products since 2018.

Keep reading

Related articles

Build with us

Interested in building something like this?

From VR training to WebGL experiences and beyond — tell us about your project and we'll scope it honestly: timeline, budget range, and the right platform.