Shipaton 2026 in Seoul: what happens after the purchase button, four demos, and a trophy
μ΄ κΈμ νκ΅μ΄λ‘λ μ 곡λ©λλ€. νκ΅μ΄λ‘ μ½κΈ° βWant to feel what the night was like? From the building session to the demos and everything in between, here's the aftermovie from Shipaton 2026: Seoul π₯.
On September 21 we ran Shipaton 2026: Seoul together with RevenueCat at MARU. About 90 people came out.
We did this last year and it was one of our favorite nights, so we brought it back with one change: more time to actually build. Shipaton is RevenueCat's global hackathon for shipping real apps to real stores, and submissions were closing at the end of September. For a lot of people in the room, this was the final stretch.
Building first
Doors opened at 4pm for λͺ¨κ°μ½: bring your laptop and work on your submission next to other people doing the same thing. It was optional, since it was a Monday afternoon, but around 30 people showed up early and got real work done before the main program started at 6:30.
The purchase button is the easy part
Jaewoong Eum, Senior Developer Advocate at RevenueCat and Google Developer Expert for Android and Firebase, gave the talk. You might know him as skydoves: his open-source libraries are downloaded more than 40 million times a year.
He started by clearing up what RevenueCat is not. It's not a payment processor. It sits on top of the App Store, Google Play, Galaxy Store and Stripe, and turns all of their billing systems into one layer.
His main point will sound familiar to anyone who has shipped subscriptions. Adding a purchase button isn't hard. The work starts after you launch, because a subscription isn't one payment. It's a lifecycle that keeps changing, and that lifecycle looks different on every store.
The hard part of running a subscription app isn't processing the payment. It's keeping every user's subscription state accurate, across every platform, over time.
He broke that down into four problems.
1. Your revenue number is probably wrong
Apple, Google and Stripe all report revenue differently: different dashboards, payout cycles, currencies, taxes and fees. Getting one accurate number often ends in a spreadsheet.
Refunds make it worse. They usually run at 3 to 5 percent depending on the category, and they can show up days or weeks after the purchase. Revenue you thought you'd earned quietly disappears.
That matters because LTV, cohorts and retention are all built on top of that number. Get LTV wrong and you can end up paying more to acquire users than they're worth, with ad campaigns that only look profitable because the revenue behind them ignores refunds.
He also made the case for splitting data by platform from day one. Download-to-purchase conversion is much higher on the App Store than on Google Play, while trial-to-paid conversion is almost the same. Average everything together and you lose the part that tells you where users drop off.
2. There is no perfect paywall
Using data from 120,000 subscription apps in RevenueCat's report, he compared hard paywalls, where users pay before using the app, with soft paywalls, where they use it for free and subscribe later.
Hard paywalls convert about five times better. But after a year, retention is almost identical: 28 percent versus 27 percent. Hard paywalls find paying users sooner and bring cash in faster. They don't keep users longer.
Pricing had a similar twist. For annual plans, lower-priced apps keep more users after a year, so a price increase that lifts revenue can still hurt once retention is counted. And introductory offers drive 65 to 99 percent of new purchases for smaller apps, but under 10 percent for top-grossing ones. Your offer strategy has to change as you grow.
The catch is that testing any of this is slow when every change goes through a developer, QA, store review and a user update. RevenueCat's answer is remote paywalls: the paywall is server-driven UI, edited in a Figma-like dashboard, and changes reach users who already have the app installed. Combine that with experiments and a product manager can test a hard paywall against a soft one, or prices by country, without anyone touching code.
One more number stuck with me. AI apps make about 41 percent more revenue per subscriber than apps in traditional categories, but churn about 30 percent faster. A paywall that works today might not work six months from now, so experimenting can't be a one-off project.
3. Edge cases are where revenue leaks
A subscription moves between states: active, grace period, expired, refunded, upgraded, paused. The happy path where the payment just works is the easy part.
Billing failures are the clearest example. On Google Play, 32 percent of subscription cancellations come from billing errors. Roughly one in three Android cancellations isn't a user deciding to leave. A grace period gives them time to fix their payment method before they lose access, but grace periods behave differently on iOS, Android and the web, and the rules keep changing.
Then there's proration. When a monthly subscriber upgrades to an annual plan mid-cycle, Google Play gives you six ways to handle it. Pick one that doesn't match what you meant and you can accidentally hand out free premium time. In his example, 10,000 users upgrading from $9.99 a month to $99.99 a year with the wrong setting could cost around $50,000. At 100,000 users, around $500,000. All from one or two lines of configuration.
And the one users notice most: getting a new phone, opening the app, and seeing "please subscribe" again because the entitlement was tied to the device instead of the account. They contact support, leave a bad review, or just leave. On your dashboard, it only shows up as churn.
4. Security and policy never stand still
Users control their own devices, so receipts need to be validated on a server, and keeping that working separately for Apple and Google is real work. Store policies keep moving too, with external payment links and regulation like the EU's DMA. RevenueCat validates receipts with the stores, signs entitlement responses to make fake premium access harder, and updates its SDK and backend when the platforms change.
His closing line: AI makes writing code faster, but billing is still a serious engineering problem when real money is involved.
Q&A
A few answers worth passing on:
- Is AI changing how people build billing? RevenueCat publishes agent skills, AI toolkits and an MCP server in its GitHub organization, so coding agents can work with its docs and APIs directly.
- Can engineers build the paywall in code instead of the dashboard? Yes. If your design team wants something custom, use the SDK's purchase and subscription APIs and build it yourself.
- Anything specific about paywalls for Korean apps? It depends a lot on the app, but Korea has rules about notifying users before a free trial turns into a paid subscription, so a smooth and clear notification flow matters.
- And the question I ask every year: if you want to get rich in Korea, App Store or Google Play first? His answer: if your users are in their 40s and 50s, publish on Google Play. If you're targeting people in their 20s and 30s, go App Store first.
Four demos and a trophy
Then the builders took over. Four people showed what they shipped for Shipaton, five minutes each:
- π Berrie Good Timer by Johanna Quinn: a timer, to-do list and notes app for juggling several creative projects at once, with hand-drawn illustrations and visual work logs. The demo walked through tracking a day's work and logging sessions.
- π¬ FICT by Sunwoo Kim: an app for generating high-quality AI videos on your phone from a simple prompt. The demo went from prompt to finished video, plus the RevenueCat monetization setup behind it.
- π£οΈ WalkLingo by Seungwoo Jo: an app for learning languages while you walk, demoed live from a phone and laptop.
- π€« hisohiso by Geusan Lim: a Japanese learning app for Korean speakers, with quizzes, text and voice.
After the audience vote, Berrie Good Timer by Johanna Quinn took home the Ship-a-little trophy π
The room
Food was the usual pizza and burgers, with the burgers from Cry Cheeseburger. The demos wrapped up at 8, but the building and networking kept going until we closed at 9:15.
Huge thanks
This event wouldn't have happened without:
- RevenueCat for bringing Shipaton back to Seoul with us
- Jaewoong Eum for a talk full of numbers every subscription app builder should know
- Hyerin Choe for helping bring the night together
- MARU for the space
- Cry Cheeseburger for the burgers
- Johanna, Sunwoo, Seungwoo and Geusan for getting on stage with what they built
- The volunteers who kept the night running: Bertijn, Brian, K, Klemen, Oscar, and Suhyun
- And everyone who came early to build and stayed late to keep talking
Watch the talk
You can find every published Dev Korea talk on our talks page.
See you at the next one.
Ready for your next move?
Visit Dev Korea to explore the latest job openings at dev-korea.com/jobs, or if you're hiring, post a job at dev-korea.com/post-a-job and connect with our growing international tech community.
