SpideyTracker

SpideyTracker is a private, real-time location and messaging app for the handful of people you actually want to always find — built like an arcade radar, not a corporate dashboard.

Comment

Devpost Submission — SpideyTracker Inspiration

Every "find my friends" app treats your location like it belongs to the platform — tracked indefinitely, stored on someone else's server, tied to a permanent account. That makes sense for a family safety app you use for years. It makes no sense for the actual common case: a group of friends at a festival for a weekend, a family road trip, a hike where the group splits up for an hour. We wanted something built for that temporary, small-group use case specifically — where sharing your location doesn't mean surrendering it forever, and where the chat you have with your group isn't sitting on a server after the trip's over. We also just wanted the UI to feel like something, not another gray dashboard with a Google Maps embed — so we leaned all the way into a retro spider-web radar aesthetic instead of fighting it.

What it does

SpideyTracker lets a small group ("a party") share live location with each other on a custom pixel-art map, chat with end-to-end encrypted messages, and drop photo pins to mark spots that matter to the group — all wrapped in a radar interface that isn't just decorative. The radar dish mirrors the map's actual viewport in real time: pan or zoom the map and the radar's blips update to match exactly what's visible, rather than being tied to fixed real-world GPS distance. Pins and live-location markers that land on the same spot automatically fan out instead of stacking invisibly on top of each other. Chat messages are encrypted client-side, decrypted and stored locally on each person's device, and removed from the relay server once every party member has confirmed receipt — the server is a relay, not an archive.

How we built it

The app is built in Flutter for cross-platform iOS/Android from a single codebase, using flutter_map for the map layer over OpenStreetMap tiles, with Firebase (Auth, Firestore, Cloud Functions, Cloud Messaging) as the real-time backend. The radar is a from-scratch CustomPainter that projects each tracked point (self, party members, pins) against the map's current MapCamera/visible-bounds rather than raw GPS bearing/distance, so it stays in lockstep with whatever the user is actually looking at. Chat encryption happens client-side before anything touches Firestore, using a local key store backed by platform secure storage (Keychain/Keystore), with messages persisted locally via Hive. The whole UI — buttons, markers, filter menus, the radar itself — follows one consistent 8-bit/pixel design language built on a shared set of custom-painted widgets rather than default Material components.

Challenges we ran into

The radar was the hardest single piece — our first version plotted blips using real GPS bearing and distance from the user's actual position, which technically worked but felt completely disconnected from the map: panning to a different city didn't change what the radar showed. We had to rebuild it to project against the map's live viewport bounds instead, so the two are actually in sync. We also hit a real cross-platform performance gap during testing — smooth on iPhones, visibly janky on flagship Android devices — which traced back to continuous animations (the radar sweep, pulsing live-location rings) sitting inside widgets with blurred shadows, forcing expensive re-blur work every frame on Android's rendering path; isolating those with RepaintBoundarys and explicitly enabling Flutter's Impeller renderer on Android closed most of the gap. Separately, we had to redesign our marker-clustering logic after finding that pins spread apart using a fixed real-world offset would silently re-collapse into a single stacked pixel once you zoomed out far enough — the offset needed to scale with zoom level, not stay fixed in meters.

Accomplishments that we're proud of

Getting the radar to genuinely feel like a real instrument rather than a decorative sci-fi prop — it reacts, it's readable, it's driven by real math against the map camera. We're also proud of taking privacy seriously instead of just claiming it: messages are actually encrypted before they leave the device, and the server-side relay design means we're not quietly building a chat archive we'd have to explain in a privacy policy later. And we're proud of the fact that the entire app — radar, chat, pins, live tracking, filters — shares one deliberate visual identity instead of feeling like several features bolted together.

What we learned

We learned how much of "performance" on Flutter is really about when things repaint, not just what they render — the Android/iOS gap taught us to think in terms of repaint boundaries and compositing layers, not just algorithmic complexity. We also learned a lot about the practical edges of local-first design: once you decide the server is a relay and not a source of truth, you have to actually think through what happens when someone's offline when a message is pruned — there's no free lunch, just an explicit tradeoff we made deliberately instead of by accident.

What's next for SpideyTracker

Push notifications for messages/live-location events, and proper phone/email OTP verification at signup (closing the "anyone can sign up with any email" gap) are both in progress. Beyond that: a "safe arrival" check-in feature for the temporary-party use case specifically, richer party history/journaling, and an actual public landing page + downloadable APK so people outside the hackathon can try it without a dev environment.

Built With

Share this project:

Updates