Inspiration
Subscriptions are everywhere now, and many of the best-value plans are designed for families or groups.
The problem is that most people don't conveniently have four or five friends who want the exact same subscription at the exact same time. So they either pay for an individual plan, start asking around in group chats in vain or end up managing the group and chasing people for money. I would know because I'm hosting both Microsoft Family and Duolingo Plan right now.
I kept coming back to a simple question: why isn't there an easier way to find people who want to share the same subscription?
That's what became Share Society.
What it does
Share Society helps people find others to share group subscription plans with on their favourite apps.
Users can browse supported subscriptions, see groups that are looking for members, and request to join one.
If there isn't a suitable group, they can start their own and find people to share with.
Once a group comes together, Share Society gives members one place to manage the group, coordinate with each other, track the relevant payment and access steps, and message other participants.
Starting groups is free for everyone. Free users can join one active group, while Share Society Pro unlocks unlimited group joins.
How we built it
Share Society is a React Native app built with Expo and TypeScript.
Convex powers the backend and realtime application state, while Clerk handles authentication.
RevenueCat and StoreKit power Share Society Pro, our monthly in-app subscription. RevenueCat entitlement state is also verified and synchronized on the backend rather than relying only on the client.
Stripe handles the separate marketplace payment flow between participants, while OneSignal provides transactional notifications and Sentry handles production error monitoring.
We also built a structured catalogue of subscription providers and plans rather than allowing arbitrary user-created listings. Pricing, plan structure and sharing economics are represented as structured product data so that users can understand what they are joining before committing.
Users are not allowed to mark up their share as Share Society is a marketplace to find people to share with, not scalping platform. This is also to be compliant with the apps' typical T&C of not profiteering from their group plans.
For release infrastructure, we use Codemagic/Expo Dev for the iOS build and release workflow, including Patch our OTA update pipeline.
Challenges we ran into
The biggest challenge was that this looks like a simple marketplace until you start modelling what actually happens.
A group can be open, full, closed, waiting for someone to leave, waiting for a payment, waiting for access, or dealing with a failed payment. A member can request to join, get accepted, change their mind, lose access, cancel, or retry. Payments can succeed while another part of the flow fails.
Those states have to remain correct even when someone refreshes the app, retries an action, receives the same webhook twice, or disappears halfway through a process.
We also handle payments on Share Society. The users can pay for annual subscriptions upfront, but we only release it to the host on a monthly basis to ensure service is rendered. This resulted in a lot of challenges beyond technicality into fairness, etc. Payments were also especially challenging because Share Society has two completely separate money systems: the Share Society Pro subscription through RevenueCat and Apple, and marketplace payments between group participants through Stripe. We had to make sure one could never accidentally imply state about the other.
We also ran into some very real mobile-release problems: StoreKit sandbox behaviour that did not always match App Store pricing metadata, native SDK configuration issues, OTA/backend version mismatches, and the usual fun of getting multiple third-party services to behave consistently inside an actual iOS release build.
Accomplishments that we're proud of
The biggest one is that Share Society became a real end-to-end product during Shipaton.
At the start of the build period, the repository foundation explicitly contained no application code. We went from that to a working iOS marketplace with subscription discovery, groups, joining and starting flows, messaging, payments, account controls, reporting and blocking, transactional notifications, and a production release pipeline.
We're also proud of how deeply RevenueCat is integrated into the actual product rather than being added just to qualify for the hackathon.
Share Society Pro has a clear role in the business model: starting groups stays free, Free users can join one active group, and Pro unlocks unlimited group joins. Purchase, restore and entitlement lifecycle handling are all connected to the real product experience.
And perhaps less visibly, we're proud of how much work went into making the underlying state safe. Payment retries, duplicate events, entitlement changes, cancellations and other failure cases were treated as real product behaviour rather than edge cases to deal with later.
What we learned
The biggest lesson was that marketplace complexity lives in the transitions between states, not in the screens.
It's easy to make a UI that says someone has joined a group. It's much harder to make sure the system knows exactly what should happen when their payment fails, the host hasn't completed setup, the user loses Pro, or the same provider event arrives twice.
We also learned to simplify aggressively.
Early versions of Share Society accumulated more flows, terminology and backend concepts than users actually needed to understand. As we tested the product, we kept moving toward a simpler consumer experience: find a subscription, find a group, join it — or start one yourself.
Finally, shipping to the App Store forced us to treat infrastructure, pricing truth, privacy, account deletion, notifications and failure handling as part of the product rather than as work to do after the "real" app was finished.
What's next for Share Society
The next step is getting Share Society into the hands of real users and learning where the strongest demand actually is. We have already launched our waitlist, but will be doing a full launch likely mid to end Oct, starting with Singapore users.
From there, we'll expand the catalogue, improve group matching and coordination, and use real marketplace behaviour to decide which subscriptions, markets and sharing models deserve deeper support.
The goal is straightforward: make sharing a group subscription feel as normal and easy as signing up for one yourself.
Built With
- clerk
- codemagic
- convex
- expo.io
- lance
- onesignal
- react-native
- revenuecat
- sentry
- stripe
- typescript
Log in or sign up for Devpost to join the conversation.