Inspiration I built SignalFire because game backlogs often become graveyards of good intentions. I wanted to solve the gap between discovering a game and actually playing it—especially when friends, platforms, availability, and multiplayer compatibility make choosing a game harder than it should be.
What it does SignalFire turns a game backlog into a playable plan. Users can discover games, save them to a backlog, track what they own and where they can play, create groups, invite friends, plan sessions, manage RSVPs, and identify games that work for the people available.
Rather than being another static game-library tracker, SignalFire focuses on the next action: what should we play, who can join, and when are we doing it?
How we built it I built SignalFire as a solo developer using Flutter and Dart for the cross-platform mobile experience. The app uses Supabase for authentication, PostgreSQL data, row-level security, storage, realtime capabilities, and server-side functions.
The architecture is designed around:
Local-first data and offline-friendly sync
Secure user, group, backlog, and session data isolation
A game-metadata integration layer for search, covers, platforms, and multiplayer context
RevenueCat-ready subscription and entitlement architecture
Idempotent actions for important flows such as planning, RSVPs, invites, and sync retries
A scalable backend path using TypeScript Edge Functions, with Go services available for high-throughput workers and realtime workloads later
Challenges we ran into The hardest problem was not displaying games—it was designing the real-world coordination layer around them.
Key challenges included:
Preventing a game backlog from becoming another passive list
Handling the difference between online co-op, local co-op, split-screen, platform ownership, and friend compatibility
Designing offline, retry, caching, and conflict-resolution behavior so users do not lose plans or duplicate actions
Avoiding confusing startup transitions, loading flashes, and disconnected splash screens
Building a secure architecture that prevents users from seeing or modifying another person’s groups, plans, backlog, or subscription state
Designing monetization that supports the product without locking away the core “play with friends” experience
Accomplishments that we're proud of As a solo builder, I am proud of creating more than a prototype screen flow. SignalFire has been designed as a product system with:
A clear core loop: discover → choose → invite → plan → play
A social planning model built around groups, invitations, RSVPs, and recurring sessions
A local-first, offline-aware architecture with queued actions and sync recovery
Security planning around Supabase RLS, user isolation, idempotency, and safe API boundaries
A scalable roadmap for metadata caching, realtime updates, background work, and subscription entitlements
A product approach that prioritizes actual play over endless browsing
What we learned Building SignalFire reinforced that the hardest parts of consumer apps are often invisible:
The best feature is not always the most technically impressive—it is the one that removes friction from a real user decision.
Reliable offline behavior, recovery states, clear error messages, and loading transitions are product features, not polish.
Security needs to be built into data ownership, API contracts, and database policies from the start.
Monetization works best when it enhances momentum and convenience rather than blocking the product’s core value.
A solo developer can move quickly, but clear architecture, testable flows, and written specifications are what keep speed from becoming technical debt.
What's next for SignalFire Next, SignalFire will focus on making game-night planning even more automatic:
Smart “Play Next” recommendations based on friends, platforms, multiplayer support, and availability
Shared group backlogs, voting, and availability polls
Recurring game nights and reminders
Better game metadata, platform compatibility, and game-session context
Subscription features that unlock advanced planning without restricting basic social play
Stronger automated testing, visual regression testing, offline sync verification, and release readiness
Expansion from a game backlog app into a lightweight coordination layer for friends who want to play more often
Built With
- dart
- flutter
- igdb
- postgresql
- revenuecat
- row-level-security
- supabase
- supabase-auth
- supabase-storage
- typescript
Log in or sign up for Devpost to join the conversation.