Ababa

Why it exists

Ababa is a mobile puzzle game built for short sessions that still feel complete: clear a level, warm up in practice, or chase a cleaner run.

The important product rule is that the core game keeps working when the network disappears. Campaign play, practice, and daily challenges start from local state, so the game can feel fast and dependable even while the broader online layer is still evolving.

Build choices

The Flutter client owns the gameplay loop, authored campaign content, local progression, settings, stats, and recovery state. The current build already includes 10 authored campaign chapters and 100 levels, with Drift and SQLite keeping the normal play experience local-first.

The backend is an enhancement layer, not the owner of solo play. FastAPI and PostgreSQL power accounts, cloud save, friends, chat, scoped leaderboards, practice sharing, realtime battles, push nudges, and operational tooling when those features are available.

Production planning is part of the project shape too: the repo includes a Hetzner deployment path for the API, Postgres, migrations, health checks, and the public Ababa website.

What it proves

• A mobile game can stay offline-first without being small in scope.
• Gameplay, persistence, localization, audio, accounts, sync, realtime chat, battles, and push can live in one coherent product surface.
• Online features can add depth without becoming a startup dependency.
• The same project can cover game feel, app architecture, backend systems, and production infrastructure.