Eyespie (formerly Scouter) is a mobile version of the game “I Spy.” It started as a prototype and went through several rewrites as I tried to reconcile a simple human game with offline play, image matching, privacy, and cross-platform delivery.
The original demo video is unavailable.
The Use Case
The core loop is supposed to be simple: one player captures an image, the app generates clues, and another player tries to find the matching object or scene. It is a social, low-friction game intended to work in a park, on a road trip, or on a hike with unreliable connectivity.
At a high level:
- Player 1 takes a picture of “the thing.”
- The device derives clues or features from the image.
- Player 2 takes a picture to guess from those clues.
- The app compares the guess with the original and produces a score.
September 2026 Design Snapshot
By September 2026, the intended MVP had been re-scoped around the essential loop rather than the larger collection of modes explored in earlier versions. The design direction was:
Player 1:
- Select “new thing” from the dashboard.
- Capture or upload an image.
Device 1:
- Derive clues and image embeddings.
- Produce any derived hint/mask data needed by the game.
- Make the game item available to the other player when connectivity exists.
Player 2:
- Select the thing from the dashboard.
- Capture or upload a guess.
Device 2:
- Derive comparable features from the guess.
- Compare them with the original.
- Score the match.
The dashboard was intentionally reduced to the actions and game items needed to support that flow.
AI and Offline Play
The design explored embeddings for image similarity because they can be less fragile than matching hand-authored labels alone. Generated imagery was also considered for hints or masks, but that remained an implementation experiment, not a proven requirement.
Offline-first behavior was the harder constraint. The game should remain useful without a reliable network connection, which pushes feature extraction and at least part of the matching workflow onto the device. That improves autonomy and privacy but increases model-size, performance, and device-compatibility costs.
Backend Direction
The September 2026 design used Supabase/PostgreSQL as the likely online coordination layer, with capabilities such as:
- vector storage/search for embeddings
- realtime synchronization when devices reconnect
- object storage for user images
- server-side functions for work that does not belong on the device
- authentication and access control
Compose Multiplatform was the cross-platform direction being explored for Android, iOS, and web. These are design choices from that snapshot, not claims about the project’s present implementation state.
What I Learned (The Hard Way)
1) Too Much MVP
The initial MVP was too large in scope. I tried to include too many modes, features, and automation in the first release. That created a long runway, complicated testing, and a lot of rework.
2) Framework Churn Is Expensive
The project moved through native Android, React Native, and Kotlin/Compose-based experiments. Each rewrite cost time and momentum while the product vision was still moving.
The lesson was not that one framework was wrong. It was that changing the foundation while still discovering the product multiplies uncertainty.
3) Business Use Cases Exploded
Even when the core game loop was stable, possible classroom, event, team-play, and monetization modes expanded quickly. That created fragmentation and analysis paralysis before the simplest version had proved itself.
4) Backend Costs and Privacy Mattered
Sharing private images raises real questions about storage, retention, consent, and who is allowed to inspect or process them. Infrastructure choices therefore became part of the product design rather than an interchangeable implementation detail.
5) Offline Support Was the Killer Constraint
A game designed for places with poor connectivity cannot treat offline behavior as a later optimization. On-device processing, delayed synchronization, and conflict handling become architectural concerns from the beginning.
Conclusion
I Spy is a simple human game with a deceptively complex implementation. The main lesson is to shrink scope, pick a stable platform boundary early, and design around the real constraints—offline use, privacy, cost, and device performance—from day one.
The concept only works if the technical choices match how and where people actually play.