Checkin: Designing a real-time social discovery platform from zero
The observation
Venues still write on chalkboards outside their front door. A band playing tonight. Half-price wings after 5. A trivia night that needs one more team.
That chalkboard works for the people walking past. But the other 10,000 people within a kilometre never see it.
I'd spent a decade leading product design across insurance, transport, and fintech. But the idea that kept pulling at me came from something simpler: watching people sit in the same room, open to meeting someone new, with no way to signal it. The tools that existed were too narrow (dating apps), too structured (event platforms), or too passive (social networks built for scrolling, not showing up).
No product answered the question: what's happening around me right now?
That's how Checkin started.
Defining the category
Before designing a single screen, I needed to understand what Checkin was. And wasn't.
I mapped the social technology landscape across two axes: spontaneity and intent breadth. Dating apps sit in the narrow-intent, semi-planned corner. Meetup sits in the broad-intent, heavily-planned corner. Social networks sit in the passive-consumption corner. The real-time, open-intent corner was empty.
I named that empty space "real-time social discovery." Not a better dating app. Not a better events platform. A different thing entirely. This framing became the filter for every product decision. When a feature didn't serve real-time, open-intent discovery, it didn't belong.
Three layers of discovery
Checkin is a platform, not a feature. It's built around three modes of real-world discovery.
Circles
Circles are small-group gatherings hosted by real people. A weekend photography walk. A Thursday language exchange. A rooftop tasting for twelve. The creation flow asks one question first: free or paid, one-off or recurring. That single fork shapes the entire downstream experience. When a host sets a ticket price, an earnings card appears showing projected revenue minus the platform fee. No surprises. Cancellation policies are grounded in Australian Consumer Law, not arbitrary platform rules.
What's On
What's On is the venue-facing layer. The digital version of that chalkboard, visible to everyone nearby. Venues post promotions that users can claim, or passive listings about what's happening. The claim flow went through several iterations before I stripped it to a single detail sheet. Tap, read, claim. One action. The friction in earlier versions was killing conversion.
Live Events
Live Events pulls from the Ticketmaster API and wraps each event with Checkin's social layer. You're not just going to a concert. You can see who else is going.
The venue side
A two-sided platform only works if both sides show up. Checkin Places is the venue dashboard. Checkin Intelligence is the AI engine underneath it, built on Python/FastAPI, surfacing foot traffic patterns and engagement insights.
I chose to never call this "AI" in the product. It's always "Checkin Intelligence." The word "AI" either over-promises or triggers scepticism. "Intelligence" says what it does without the baggage.
Area Intelligence shows venues what's happening around them, not just inside their walls. Boosts let them amplify visibility during quiet windows. Both designed around the same principle: venues shouldn't have to guess when to promote.
Design decisions that shaped the product
The Stripe rejection
Stripe restricted Checkin's account. They classified the platform as "matchmaking" because the nearby-people feature surfaced users to each other. The appeal failed.
I moved to Square. But it wasn't a simple swap. Square's in-app payments SDK works differently. Apple Pay required a separate Payment Processing Certificate through Square's CSR process. Google Pay had its own configuration.
The design consequence: I had to build a payment experience that felt seamless while working within Square's specific constraints. The earnings preview in Paid Circles, the platform fee transparency, the weekly payout model with a 7-day hold and $20 minimum. All of these were shaped by the constraint, not designed in spite of it.
Some of the best product decisions come from a door closing.
Navigation restructure
The original bottom navigation grouped What's On under a broader discovery tab. User behaviour told a different story. People were checking What's On like a feed, not navigating to it as a subsection.
I moved What's On to its own tab and consolidated connection requests under Messages. Four tabs instead of five conceptually overlapping items. A small change in the nav bar. A significant shift in how the app communicates its purpose.
Privacy as a design constraint
Privacy isn't a feature in Checkin. It's a constraint that shapes everything.
Users see who's nearby, never where exactly someone is. Push notification payloads use a firstNameOnly() utility. No surnames leak. Ghost mode is one tap away. Check-in is opt-in only. You're never visible unless you choose to be.
These aren't policies. They're architectural decisions baked into the data model, the API layer, and the UI.
Copy as product design
Every piece of microcopy follows one rule: write it the way a person would say it.
Account deletion doesn't say "We're sorry to see you go." It says what's happening, what you'll lose, and how to proceed. Notification preferences use plain descriptions, not toggles labelled "Marketing communications." No filler words. One idea per sentence.
This isn't style. It's a design decision rooted in the product's purpose. Checkin is about real human connection. If the app talks like a brochure, it undermines its own promise.
Building it solo
I designed and built the entire platform. Flutter mobile app. Node.js backend with PostgreSQL. Python/FastAPI AI engine. Next.js web services for Circles Web and Places. All deployed on Railway.
My workflow: planning sessions for product and design decisions, detailed implementation prompts, execution through Claude Code. This lets me operate as a solo founder without compromising on architecture. Every technical decision is a product decision. I don't have the luxury of throwing it over a wall.
Shipping to production surfaced problems that staging had hidden. A critical Square Application ID pointing to sandbox instead of production. Database migration conflicts between services. Domain and DNS configuration for circles.check-in.au. A QA audit produced 21 prioritised issues. All resolved.
The discipline isn't heroic debugging. It's building a process for catching problems before users hit them.
What this work shows
Category thinking before pixels. I defined the landscape, found the gap, and used that frame to guide every decision. Features that didn't serve real-time social discovery got cut. No matter how interesting they were.
Designing under real constraints. A payment processor rejection. App store rejections. Privacy regulations. Consumer law. A solo team with zero budget. These constraints shaped the product. The best decisions came from working within them.
End-to-end ownership. Market analysis to interaction design to production code to app store submission. Most designers hand off. I ship.
Systems thinking across a platform. Consumer app, venue dashboard, AI engine, web platform, payments integration. All designed as a coherent system. The decisions in one layer affect every other. That kind of thinking scales to any product organisation.