Evrystone: Building a Gamified Habit Tracker That Turns Daily Non-Negotiables Into a Game Worth Winning

Evrystone is an internal Lasana product currently in private beta. It is a mobile-first habit tracker built on the simple premise that daily non-negotiables, the small commitments that compound into a life, deserve the same engagement design that consumer apps use to keep people scrolling. We are building it for ourselves first, then shipping it to anyone who wants the same edge.

This case study walks through the product vision, the technical architecture behind Evrystone, the design decisions that shaped the gamification loop, and the engineering challenges of building a cross-platform habit app with real-time sync, offline support, and push reminders on a single shared codebase.

The Problem We Set Out to Solve

Most habit trackers fall into one of two failure modes. They are either checklists with notifications, dry and easily ignored, or they are over-gamified pet simulators where the metaphor gets in the way of the work. We wanted to build something that respects the user's intelligence while still leveraging the engagement mechanics that decades of game design have proven work.

1. Habit Trackers That Feel Like Chores

Plain checklist apps treat habit-building as a clerical task. There is no momentum, no feedback loop, no reason to come back when motivation dips. Users abandon them within weeks because the app does nothing to make the next day feel worth showing up for.

2. Gamified Apps That Bury the Habit

On the other end, some habit apps wrap everything in a fantasy metaphor. The user is no longer building a meditation practice, they are feeding a virtual pet. The gamification becomes the focus, the habit becomes incidental, and the long-term behavior change never lands.

3. Streaks That Punish Real Life

Most streak-based apps treat a single missed day as a total reset. This is psychologically backwards. Users who miss one day often quit entirely rather than start over from zero. The "all or nothing" streak model creates exactly the rage-quit moment the app should be designed to prevent.

4. Reminder Noise

Reminder fatigue is a real failure mode. Apps that default to aggressive notification schedules quickly get muted, uninstalled, or have their permissions revoked. Reminders need to be configurable, intentional, and respectful of the user's actual schedule.

5. No Long-Term Reinforcement

Even when a user successfully completes their daily habits, most apps fail to surface the long arc. A user three months into a workout streak should feel that weight. The app should make the cumulative effort visible in a way that creates emotional investment in not breaking it.

The Solution: Evrystone

Evrystone is a mobile-first habit tracker designed around a single core loop: define your daily non-negotiables, get reminded, complete them, build streaks, earn experience and badges, repeat. Every design decision serves that loop.

Flexible Task Types

Habits do not all look the same. Evrystone supports multiple task types so users can model their actual commitments:

• Checkbox tasks: Binary done/not-done. "Did you work out?"
• Counter tasks: Accumulate toward a numeric target. "16 of 64 oz of water"
• Timer tasks (v1.1): Duration toward a target. "30 minutes of reading"
• Checklist tasks (v1.1): Multi-item, all must be checked. "Morning routine: brush, floss, vitamins"

Each task has a cadence (daily, weekly, or monthly) and an optional list of reminder times. The user is in full control of what gets tracked and when.

RPG-Style Progression

Completing tasks awards experience points. XP is weighted by cadence so that weekly and monthly commitments are valued appropriately against daily ones. The level curve follows a classic exponential RPG progression, meaning early levels come fast and feel rewarding, while higher levels demand sustained consistency.

This is not a gimmick. It is a system designed to give users a quantifiable, growing measure of their own discipline.

Streaks With a Safety Net

Each task tracks both a current streak and a longest streak. To solve the rage-quit problem, Evrystone uses freeze tokens (v1.1), earned by completing a perfect week. A freeze token can be spent to preserve a streak after a missed day. This is a proven retention mechanic borrowed from apps like Duolingo, and it acknowledges a simple truth: long-term consistency is more important than perfect consistency.

GitHub-Style Heatmap

The Stats tab features a year-at-a-glance heatmap calendar. Each cell represents a day, with color intensity tied to the percentage of that day's tasks completed. A green wall of squares is one of the most satisfying visualizations in software, and it gives users an honest, undeniable view of their consistency over time.

Curated and Auto-Generated Badges

The MVP ships with around ten curated badges, things like "7-day water streak," "30-day workout," "First month perfect," and "Early bird." On top of that, any task that hits a 7, 30, 100, or 365-day streak automatically earns a generic milestone badge. The badge system rewards both specific behaviors and raw consistency.

Onboarding That Respects Time

New users see a single onboarding modal with a grid of preset habit chips: Workout, Water, Reading, Meditate, Sleep, Steps. Tap to pick a few, hit Done, and the tasks are materialized in Firestore and ready to track. Total setup time is under a minute. Presets intentionally ship without default reminder times, so day one is noise-free. Users add reminders when they actually want them.

Production-Grade Architecture

From an engineering perspective, Evrystone is built to scale from a single user to a global user base without rearchitecting. Every layer was chosen for a specific reason.

Mobile: Flutter

The mobile app is built in Flutter, giving us a single Dart codebase that compiles to native iOS and Android binaries. This is not just a cost decision, it is a quality decision. Every feature ships on both platforms at the same time, with identical behavior, and there is no second-class platform that lags behind.

• Local notifications via flutter_local_notifications for reminders that work offline
• Push notifications via Firebase Cloud Messaging for server-driven nudges
• Offline cache via the Firestore SDK, so the app works on planes, subways, and bad cellular

Web Companion: Next.js

A Next.js web companion (v1.1) provides a desktop dashboard for users who want to manage tasks, review history, or do bulk edits at a real keyboard. It shares the same Firebase backend as the mobile app, so state stays in sync across devices in real time.

Backend: Firebase

Evrystone is built on the Firebase platform end to end:

• Firebase Auth for email/password and Google sign-in at MVP, with Apple sign-in added for iOS App Store compliance in v1.1
• Cloud Firestore for real-time sync, offline caching, and per-user security rules
• Cloud Functions for scheduled jobs: period rollovers, reminder dispatch, streak rollups
• Firebase Cloud Messaging for cross-platform push notifications
• Firebase Analytics from day one, so we can measure what actually drives retention
• Firebase Hosting as the deploy target for the Next.js companion

This stack gives us one auth identity per user across mobile and web, real-time sync without writing socket code, and a unified deployment story.

The Period-Doc Data Model

One of the most important architectural decisions was how to handle daily, weekly, and monthly resets. Naive approaches mutate task state at midnight, which creates race conditions, requires careful scheduling, and makes history queries painful.

Instead, Evrystone uses a period-doc model. Each period (a day, week, or month) gets its own Firestore document, keyed by a period identifier like 2026-04-13, 2026-W15, or 2026-04. Completing a task writes to that period's document. "Resetting" at midnight is no-op, the app simply queries the next period's document, which starts empty.

This has three big benefits:

• Zero mutation on rollover: No scheduled job needs to touch anything to "reset" a user's day
• Clean history: Every period is a self-contained record, immutable after it passes
• Trivial queries: "Show me April" is a single document range read

Indexes and Range Queries

The heatmap needs to load 365 days of completion data efficiently. We use Firestore field overrides on the dayKey field for both collection and collection-group scopes, so range queries stay indexed without paying for indexes we do not use. New entry writes set dayKey equal to the period doc id; legacy docs without dayKey fall back to a document-id range read.

Security Rules

Every user document and subcollection is locked to the authenticated user. The rule is one line: allow read, write: if request.auth.uid == uid;. Firestore enforces it at the server, so there is no path to another user's data even if the client is compromised.

Reminder Logic That Respects the User

Reminders are split between local and server-driven, because each has different strengths:

• Local notifications fire on the device without needing connectivity. They are scheduled by the app based on the task's remindAt times and the user's timezone
• Push notifications are dispatched by a Cloud Function that runs every 15 minutes, checks which users are in a matching local time window with incomplete tasks, and sends FCM messages
• Last-call nudges fire one hour before a period ends if tasks remain incomplete, a final gentle prompt before the streak is at risk
• Snooze on a notification skips the next reminder window for that task, so the user can defer without losing the day

Reminders are opt-in per task. Presets ship with no reminders set. Users decide what is worth being interrupted for.

User Experience Decisions

Engineering an app like Evrystone is as much about what you choose not to do as what you build. A few decisions that shaped the UX:

Three Tabs, No Clutter

The post-auth shell has exactly three tabs: Home, Stats, Profile. No tasks tab (Home is the task list). No social tab (v2 territory). No settings tab (settings live in Profile). The information architecture is intentionally minimal.

Modal-for-All Completion

Tapping a task on Home opens a small progress modal rather than toggling completion inline. This prevents accidental updates (a tap while scrolling no longer fires off an XP award) and gives counter tasks a proper input surface with +/- buttons and quick-add chips.

Gilding, Not Greying

Completed tasks on Home get a gilded golden accent instead of being greyed out. Completion should feel rewarding, not finished. A 100% day gets gilding plus a subtle celebration. This is a small detail with a real motivational payoff.

Task Library, Not "Create Task"

The Home FAB opens a Task Library, not a blank create form. Users can toggle presets on and off, edit any task, or create a custom one from a single surface. Disabling a task preserves its history and streaks, mapping to the archived flag rather than deleting data.

Account Deletion in MVP

Apple's App Store guidelines require any app with account creation to also provide in-app account deletion. We shipped this in MVP, with a confirmation dialog and a Cloud Function that wipes all user data from Firestore and Auth. Skipping this would mean a guaranteed App Store rejection.

Technical Challenges We Solved

1. Timezone-Correct Rollovers Across a Global User Base

Period boundaries are computed in the user's local timezone, not UTC. A user in Tokyo and a user in Los Angeles see their day reset at their local midnight, not Google's. Each user's timezone is stored on their profile and respected by both the client and the rollover Cloud Function. This sounds obvious in writing but is a frequent source of bugs in apps that scale.

2. Offline-First Without State Drift

Users complete tasks on subways and airplanes. The Firestore SDK handles offline caching, but we still had to design completion writes to be idempotent: toggling a checkbox twice should not award XP twice. XP and streak updates happen in transactions on the server side to prevent race conditions when a device reconnects with pending writes.

3. Heatmap Performance at Scale

Loading 365 days of entries on every Stats open would be expensive at scale. The current implementation uses indexed range queries scoped to a single year. The roadmap includes optional rollup documents (heatmapSummary/{year}) written by a Cloud Function, so the Stats tab opens in one read instead of 365.

4. Swappable Service Layer for Faster Development

Early in the build, we worked behind mock service layers (MockAuthService, MockTaskRepository) so UI development could proceed before Firebase was wired up. This meant every screen was built against a clean abstraction. Swapping in the real Firebase implementation later required zero changes to any screen code, just dependency injection at the app root.

5. Single Codebase, Two Stores, Two Sets of Rules

Shipping on both iOS and Android means navigating Apple's strict review process and Google's notification permission model simultaneously. We baked Apple's account-deletion requirement into MVP, implemented Android 13+ runtime notification permission prompts, and unified the build pipeline so a single flutter build invocation produces release artifacts for both stores.

Where Evrystone Is Today

As of this writing, Evrystone is in private beta preparation. All MVP UI screens are built and wired to Firebase. The data model, security rules, indexes, and the daily streak rollover Cloud Function are deployed. The next steps are the external work the codebase cannot do for itself: Apple Developer setup, App Store Connect listing, Play Console internal testing track, APNs auth key upload, Crashlytics dSYM upload, and a smoke test pass on real devices.

Beyond beta, the v1.1 roadmap adds the Next.js web dashboard, timer and checklist task types, freeze tokens, more badges, categories and tags, and Apple sign-in. v2 brings social features (friends, leaderboards, shared challenges), themes, a paid tier, and home screen widgets for iOS and Android.

Why We Are Building This Ourselves

Most of Lasana's work is for clients. Evrystone is different. It is an internal product, built to scratch our own itch and to demonstrate what we can do when we own the entire stack: product, design, engineering, deployment, and marketing. The same tools we use to ship for clients (Flutter, Firebase, Next.js, Cloud Functions) are the tools we used to build Evrystone, on the same timelines and with the same discipline.

If you are evaluating Lasana for a mobile or full-stack project, Evrystone is the most direct answer to the question "show me what you can build." It is a real product, with real users, designed and engineered end to end.

Conclusion

Building Evrystone is an exercise in taking the engagement design lessons of the consumer app world and applying them to something genuinely useful: helping people show up for themselves every day. The technical foundation, Flutter, Firebase, period-doc data modeling, server-side streak rollups, is built to scale. The product design, gilded completions, RPG progression, freeze tokens, year-long heatmaps, is built to make consistency feel as rewarding as it actually is.

If you would like early access to the Evrystone beta, or you are considering a similar mobile-first product and want to talk about the architecture, design decisions, or stack choices that shaped it, we would love to hear from you.