Inspiration I live in Florida. My D&D group lives in the Netherlands - except for one player, who's in Finland. For a while we made it work. Then adult life happened: jobs, partners, kids, a significant time difference, and a Discord channel where "can everyone do this Sunday?" would sink under forty messages of memes before three people had answered. The night that broke it for me, I logged on for a session and sat there alone. Half the table never showed. Not because they didn't want to play, but because they'd never read the message, and nobody noticed that no response isn't the same as yes. That's the entire problem, and it's not a people problem. Group chats are structurally terrible at scheduling because silence and agreement look identical. There's no state. Nothing anywhere tracks who is actually in, so the organizer becomes a human polling loop, and eventually the organizer gets tired and the campaign quietly dies. So I build the thing I wanted: a place where proposing a game night creates a small piece of shared state that everyone can see, that chases people on its own, and that resolves itself without anyone having to play secretary. What it does Next Session runs one loop: Propose → Vote → Confirm. Someone proposes a session from a list of dates where enough group members are available, the group votes, and the session automatically locks itself in once enough people accept. Conversely, when enough people decline, it denies itself instead of sitting in limbo forever. Each group sets how many players can be missing and still play, so a five-person table with a threshold of one locks in at four accepts. Everyone also keeps a personal availability calendar - recurring ("never Mondays), plus one-off overrides - which aggregates into a group view so a proposer can see which days are actually open before proposing. And then the part I'm proudest of: the auto-scheduler. Turn it on, pick a time of day, and the moment one session wraps, Next Session searches forward for the first date the table is free and proposes the next one by itself. No rule to write, no cadence to configure. You stop scheduling entirely; sessions just keep appearing. That feature is free. More on why below. How we built it Flutter and Material 3 on the front end, shipping to Android and the web from one codebase, with a genuinely separate desktop layout rather than a stretched phone UI. go_router for navigation, Riverpod for state, as recommended by the wonderful CodeWithAndrea. Firebase for everything behind it: Auth, Firestore, Cloud Functions, Storage, Cloud Messaging, App Check. Monetization though Revenuecat - purchases_flutter on mobile, and Revenuecat's web integration with Stripe for browser purchases. Because Next Session spans web and Android, tracking subscription state across platforms could have been painful. Revenuecat eliminated that headache by flawlessly syncing entitlements between Stripe and the app. AdMob on mobile for the free tier. The architectural decision I'd defend the hardest is that schedule is event-driven, not a cron sweep. The obvious way to build recurring session is a periodic job that wakes up and asks "does anything need generating?" I did it the other way: exactly one upcoming session is ever in flight per group, and the next one is generated by a Firestore trigger the instant the current one resolves - completes, gets canceled, or fails to vote. There's no polling and no drift. Firebase Cloud Messaging ties directly into these event-driven triggers, making the localized push alerts fire instantly without needing a polling loop. That one choice removed a whole category of UX I never had to design. Cancelling an auto-scheduled session is just... cancelling a session. There's no "this occurrence / this and following / the entire series" modal, because there is no series sitting in the future - only the next one, which generates from the current state whenever the current one ends. The feature got simpler to use and cheaper to run at the same time, which almost never happens. The transatlantic table shaped a lot of the rest. Every notification is rendered in the recipient's own locale and local time, because "Sunday 19:00" means two different moments to me and my group. The app ships localized, and the server-side notification copy is localized too - a Dutch player gets Dutch push notifications about a session an American proposed. What we learned Deciding what's free is a product decision, not a pricing one. I originally gated the auto-scheduler behind the paywall - it's the flagship feature, so it seemed obvious. Then I reversed it, and I think that reversal is the best call I made. The auto-scheduler is what makes the app sticky: a group that turns it on never has to think about scheduling again, so they keep coming back, and free users monetize through ads anyway. Paywalling my own retention mechanic would have been charging for the reason to stay. Next Session+ now sells the refinements around it - recurring rules with full cadence control, calendar sync, vote reminders, custom group images, and no ads. Building is the fun part; marketing is the work. My landing page sat live for two weeks with essentially no organic traffic. Nothing about writing good code causes anyone to find you! Compliance isn't a checkbox when your users are the ones it protects. My actual players are in the EU. Analytics ships off by default, region-scoped: opt-in for the EEA/UK/Switzerland, opt-out elsewhere, with consent revocable from Settings at any time. It wasn't theoretical - I was building it for my friends.

Next Session

Coordinate campaigns, not calendars.

Coordinate campaigns, not calendars.