How to Find and Validate a Shipaton Idea in Three Days

App Store releases have exploded, and the reason isn't mysterious: the tooling got good. What got expensive is deciding what to build — because, as RevenueCat's Rik Haandrikman put it on a recent Shipaton live stream

AI can also help you build the wrong thing at unprecedented speed, and in the process burn through many, many, many tokens.

Shipathon runs from August 1 to September 30, with over $700,000 in cash across categories like Build & Grow, Best Game, #BuildInPublic, and five influencer awards. Two months might not sound like a lot of runway, but if you’re just getting started, spending three days making sure you're building the right thing is the highest-leverage trade you can make. Here's the playbook from RevenueCat's livestream on finding and validating your app idea.

Start from your unfair advantage

Good ideas come from a perspective nobody else has, which comes from three places:

Who you are.Building for people like you gives you a first user who is infinitely accessible. You never have to ask permission for your own time.
Who you know.With an audience already in hand, you've solved distribution before you've solved product. It's why influencer-fronted apps work, and why Shipaton has- five influencer awards this year: five creators have each described a problem they want solved, and building for one keeps you eligible for every other prize too.
What you know.Specialized knowledge or lived experience that gives you an unusual understanding of a problem. Another version of this is "what feels like play to you but looks like work to others.” Practical advice, because you'll stick with play longer than a slog.

The idea usually hides in your own week: a task you keep repeating, something your friends constantly ask you for help doing, or something you quietly wish were less annoying.

Then make it smaller

The temptation is to make it bigger. Resist. Fill in four blanks: for whom, when they need it, what outcome they get, and how.

At the Shipaton kickoff in Japan, a developer pitched an app that listens to a film's audio and streams live translated subtitles to your phone, for someone watching an untranslated anime in a Tokyo cinema. Four blanks, filled sharply. Then mid-conversation he widened it: also useful at the convenience store, at the doctor's, chatting on the street. Within a minute he had, in Rik's words, reinvented "shitty Google Translate", and acquired Google as a competitor he hadn't had thirty seconds earlier.

Everyone does this, because a billion users feels better than a thousand. Deciding who your app is not for is what keeps you out of fights you can't win.

The four-part test

Can you describe who it's for, specifically enough?
Is the job you solve dramatically better with your app?
What's your unique edge? Why do you beat the incumbent?
Can you actually reach people who'd try it?

Three out of four is the bar. The fourth you can usually figure out from there. Reach is where people stall, and nine times out of ten that's a symptom rather than the disease; the person isn't defined sharply enough yet. A developer pitching a quit-smoking app for Japan asked how he'd find users. Tokyo packs its smokers into glass cabins all over the city, and he was a Japanese smoker. His first five users were standing in a box waiting for him.

Build the trailer before the movie

A trailer costs a fraction of the film and still tells you whether anyone wants to see it. Validate the same way: at each step, spend as little effort as possible and ask as little as possible of the person you're testing on. Only climb a rung once the last one gets a real reaction.

Say it out loud.Describe the problem and your fix to someone. That’s it.
Show three screens.Mock up the core flow, put it in front of them, and watch where they hesitate.
Run a fake front door.Put up a store page or landing page for an app that doesn't exist yet and see who clicks. Adam Lyttle did exactly this –- a web-to-app funnel with nothing behind it – to test demand before building anything. It's the old mobile gaming trick: run ads for 10–20 concepts, prototype only the top three by click-through rate. Use paid ads for this rather than your own following; sending your community to an empty page costs more goodwill than the data is worth.
Build the magic moment (and nothing else).The subtitle app needs no login, no settings, no onboarding to prove itself. Audio in, live subtitles out. That's the entire prototype.

A common mistake in the “AI era” is jumping straight to step 4 (or past it to a finished app), simply because you can. Being able to build the whole thing in a day is not a reason to.

Look for receipts, not compliments

Your mom thinks your idea is great. That's lovely and it's worth nothing. But you want evidence, in escalating order:

Pain: without your app they're stuck. "I want to see that movie but I won't go."
Interest: they start asking questions. How does it work? Can I try it Friday?
Commitment: they pay, share, or give you time. One team building a yoga app for an existing community ran a pre-sale before writing a line of code.

Question shape matters enormously. "Would you use my amazing AI caption app?" produces warm words and zero signal. "Tell me about the last time you hit this problem" produces a story you can act on… then ask whether they'd use something that fixed it. And always take contact details, then follow up at every stage: people who helped shape a half-formed idea have a little of themselves invested in it, and by launch day that first scrappy cohort are your ambassadors.

The three-day loop

Day 1:Talk to five people about the problem. Not the app! The problem.
Day 2:Build the magic moment. Paper prototype at minimum; it's 2026, so realistically a semi-working PoC on a device.
Day 3:Ask for commitment. A trial, a share, a payment.

After each day: build, bend, or bin. Bullseye, keep going. Close but not quite, tweak and repeat the step. Miles off, build something else. Time-box it ruthlessly.

Lastly, make your app vividly describable

RevenueCat’s Developer Advocate, Rhys, built an app called Touch Grass. The name and one-sentence description alone handle the part of the distribution challenge. Touch Grass: it blocks your apps until you touch grass.People visualize that instantly, which is what makes it shareable with no budget. Test your sentences on friends and watch their faces. Rhys builds funny, tongue-in-cheek apps, so something as simple as a laugh can be a green light.

Then post the ugly version. Touch Grass's first public build looked (very) unpolished, and Rhys put it on Reddit three months before launch. It got 800 upvotes and 80,000 views. Today it's at 125,000 downloads on a RevenueCat subscription. "I've got no ad budget. I've got no team. I'm just a guy."

One practical hurdle on the way out: new personal Google Play accounts need a closed test with at least 12 testers opted in for 14 continuous days before applying for production access. That tripped up a lot of submissions last year, so start now and use the Shipaton Discord's tester channels.

Remember: don't follow your heart. Follow the receipts!

Shipaton 2026 runs August 1 – September 30, 2026, with submissions closing September 30 at 11:45pm Pacific. Vibe coding is fully allowed — RevenueCat only cares that you ship a real app to the App Store, Google Play or Galaxy Store. Details at