Habiv
AI game platform · full-stack engineering · 2026
A browser-first home for tiny 10–45 second games: discover, play, remix, and share games made by people and AI agents.
Live browser-first product
the problem
AI-made games were easy to generate but difficult to experience as a product. They lived in chats, folders, and one-off demos, while players had no focused place to discover short games, creators had no publishing loop, and the platform had to keep untrusted game code away from the main app.
technical context
- Playable game bundles are untrusted code and must remain isolated from the main application and its user session.
- Publishing needed a repeatable path from an uploaded bundle or agent output through inspection, conversion, thumbnails, and smoke testing.
- The platform combines public browsing and playback with authenticated creator tools and persistent game metadata.
- Storage, ingest jobs, analytics, runs, and leaderboards had to support both player and creator workflows.
my role and technical scope
I led full-stack product engineering from the first interface through the creator platform. I built the browse and play surfaces and connected them to identity, catalog data, object storage, ingest and conversion jobs, analytics, leaderboards, and agent publishing.
architecture and engineering decisions
- Separated the game runtime onto its own origin to isolate playable bundles from Habiv cookies and application context.
- Kept the public catalog and playback surface separate from authenticated publishing, account, and creator operations.
- Built ingest and conversion steps to inspect uploaded bundles, detect engines, generate thumbnails, and smoke-test builds.
- Added an MCP publishing route so agents can submit games into the same processing pipeline as creators.
what shipped
- Responsive home feed with featured games, category navigation, search, saved games, history, and a creator profile surface
- Watch pages with an embedded player, prompt and version history, comments, leaderboard, and related-game queue
- Creator workflows for publishing, editing, visibility, store art, settings, API tokens, and MCP connection details
- Platform foundations for Supabase identity and catalog data, R2 game storage, ingest/conversion jobs, analytics, runs, and leaderboards
outcomes
- Shipped a live browser-first game platform at habiv.com with public play and creator publishing workflows
- Separated untrusted game execution from the main application context
- Connected the marketplace interface to storage, ingest, analytics, runs, and leaderboard systems
engineering priorities
- Bundle validation and conversion success rates
- Game startup time and runtime error rates
- Isolation checks for game execution and user sessions
- Reliability of publishing, analytics, and leaderboard updates
what I learned
A safe runtime is part of the platform architecture from the start. Separating game code from application sessions shapes storage, publishing, and playback decisions across the system.
engineering strengths demonstrated
- Full-stack product engineering
- Secure runtime boundaries
- Ingest and conversion pipelines
- MCP and creator integrations