YoMaxi: Making everyday progress feel rewarding.

YoMaxi started as something I wanted for myself: one place to organise the parts of life that matter and stay consistent with them. I built it around goals, habits and tasks, with a friendly sidekick, achievements and levels. It began as LifeOS, is under active development and is not yet released.

How it is being built

Six stages of the classic product cycle, from a personal brief to a build in progress; AI works with me at each one, and the decisions and the quality bar are mine.

1. 01

   Ideation and screening

   4 September 2026Done

   The brief was a list of ordinary, easily neglected commitments (appointments, water, supplements, walking, saving, birthdays) that I wanted in one view of life and progress.

   My role

   I wrote the brief and framed the problem: the areas of life, the role of gamification and the integrations I wanted.

   Decisions

   • Goals, habits and tasks, so that every action links to a larger objective.
   • Life areas, not one list, because a single list was the problem.
   • Gamification in support, not in charge, because the aim is real-life action.

   Outcome

   The LifeOS concept: connect everyday actions to larger objectives and make progress visible across the areas of life.

   Challenges

   Breadth: an app that spans every area of life can become a list of everything, and a list was the problem.

2. 02

   Product definition and planning

   5–12 September 2026Done

   The specification ran from v0.1 on 5 September to v0.3 on 12 September: product brief, React Native and Expo engineering baseline, and the AI-assisted workflow.

   My role

   Product owner: I set the questions, chose the priorities and decided what each version committed to, with AI drafting alongside.

   Decisions

   • One habit, offline, rewarded once, first, because that is the hard part.
   • Offline-first with an outbox, because core actions must work without a connection.
   • Calendar and health integrations behind spikes, because I promise nothing unproven.

   Outcome

   A specification to build from: domain model, scoring and sync rules, fourteen acceptance scenarios, five milestones and a marketing strategy draft.

   Challenges

   Deciding what stays out: bank aggregation, medical recommendations, social feeds, leaderboards and an LLM coach all sit outside the MVP.

3. 03

   Design and prototyping

   September 2026Done

   I moved the early tactical, game-inspired direction to a flat, minimal cartoon look: Maxi on a warm cream canvas, two themes, one component set.

   • 

   • 

   • 

   • 

   My role

   Creative direction and design system: I set the brief, directed each revision and built the brand book, components and screens in Figma.

   Decisions

   • Flat cartoon, not tactical, because personality must not cost clarity.
   • Both companions on the welcome screen, so that the choice is real.
   • One component set for both themes, so that nothing depends on the choice.

   Outcome

   A full design system in Figma (brand book, foundations, components and thirty-nine screens) that every screen since is built against.

   Challenges

   Staying age-independent without a toy-shop feel; and production artwork for Maxi, every pose at three densities, is still outstanding.

4. 04

   Validation and testing

   September 2026 – presentIn progress

   Validation so far is engineering validation: test-first feature work, fourteen mandatory scenarios and CI gates; no user testing has run yet.

   My role

   I set the quality bar (no duplicate rewards, durable offline writes, account isolation) and the scenarios that prove it.

   Decisions

   • Never reward the same completion twice, because progress must stay believable.
   • Consistency apart from lifetime XP, because past effort and current routines differ.
   • Test-first for every domain rule, because a green build must mean something.

   Outcome

   Fourteen scenarios, QA-01 to QA-14, from a retried completion to a time-zone change; the main branch protected behind three required checks.

   Challenges

   Historical CI runs still show failures, and the XP values, seven-day window and reminder defaults await user testing.

5. 05

   Development

   8 September 2026 – presentIn progress

   Foundation, slice and core build, with Claude Code as coding assistant: one habit completed offline and rewarded once, then programmes, goal steps and money on top.

   • 

   • 

   • 

   • 

   My role

   Engineering lead with AI-assisted implementation: I choose the next slice, decide what is startable and review the diffs.

   Decisions

   • Custom sync through an Edge Function, so that client and server share one contract.
   • A plan is a queue, not a calendar, so that a missed day waits.
   • Money by hand first, because spending by category waits on a bank feed.

   Outcome

   Core loop, plans, programmes, projects, events and reminders on Supabase EU; 2,022 tests on every change; a release APK in CI.

   Challenges

   iOS has never been compiled, so cross-platform is unproven; meal and event sync is written but not deployed.

6. 06

   Launch and commercialisation

   Planned

   Ahead, with no dates: a core beta with users, an integration beta and release readiness; the brand and the two commercial concepts are the preparation so far.

   • 

   • 

   Play video

   Play video

   My role

   Brand and promotion direction: AI explored names, logos and commercial concepts; I chose YoMaxi and directed the narrative and character.

   Decisions

   • YoMaxi, Maxi as the companion, because the name is the greeting.
   • Lead with the sidekick, not features, because the emotional idea comes first.
   • The hologram stays an advertising effect, so that nobody reads it as a feature.

   Outcome

   A usable identity (wordmark, compact logo, three variants) and two commercial concepts; no beta, listing or users yet.

   Challenges

   Distinctive without becoming childish took four working names; a name is not a clearance: no trademark is established.

What exists today

• 7life categories
• 2themes, one component set

Product model and brand

• Goals, habits, tasks and calendar events across seven life categories; Mind & Balance added as the seventh
• Brand: YoMaxi, its companion Maxi, two complete themes sharing one component set

Built so far

• Core loop: create a daily habit, complete it offline, see provisional XP, restart, sync, undo (never rewarded twice)
• Training plans; goal steps with milestones; first-tier money tracking
• Programmes for nutrition, Mind & Balance and Family & Social
• Work category built around projects, with setup templates that create and let go rather than enrol
• Events with reusable checklists that become real dated tasks
• Task reminders, quick capture, a daily priorities pick
• Today screen groups tasks under their programme, project or event; a programme task says why it is there
• Meal recording, with food-packet barcodes looked up on Open Food Facts
• A launch page that takes waitlist sign-ups

Active development. Not released: no store listing, no public beta, no users, no retention or wellbeing figures. Calendar and step-tracking integrations are planned; Ask Maxi ships as a static screen.

Technical specs

• 68screens
• 2,022tests per change
• 375rendered tests
• 20migrations
• 3required checks

Platforms

• Android: built and run on an emulator and on my own phone; CI builds a release APK for the nightly device tests
• iOS: configured under the same bundle ID, not compiled yet
• Web: a development preview through react-native-web, with data held in memory

App

• Expo SDK 57, React Native 0.86, React 19.2 and TypeScript 6 in strict mode
• Expo Router with typed routes: four tabs, then modal, onboarding and account groups
• SQLite on the phone through expo-sqlite; the session in secure storage
• Local reminders planned seven days ahead, at most 60 pending; no server push
• English only for now, with dates, counts and money formatted through Intl

Architecture

• An npm workspaces monorepo: the app plus domain, contracts and theme packages
• Domain rules are pure functions with no clock and no randomness, so the phone and the server run the same code
• Offline first: a change and its outbox entry commit in one SQLite transaction
• Sync pushes and pulls at sign-in, when the app comes back to the front and every 60 seconds while it is open
• A Supabase Edge Function on Deno checks each batch against the shared contract and works out XP on the server
• A retried operation comes back as a duplicate; an edit made against an old version is refused as a conflict

Backend

• Supabase in the EU: PostgreSQL, Auth, and Edge Functions for sync and the launch-page waitlist
• Row-level security on every user table, so one account cannot read another's rows
• A unique index allows one reward per source; an undo appends a correcting entry and deletes nothing

Quality and CI

• Node's built-in test runner across six suites: domain, contracts, schema, theme, app and rendered screens
• Migrations tested against real PostgreSQL compiled to WebAssembly (PGlite)
• Screens mounted through react-native-web; a gate fails when a new screen has no rendered test
• GitHub Actions on every change: a typecheck, a design-token drift check and coverage floors
• Line coverage floors of 99% for the domain rules, 97% for app logic and 92% from the rendered tests alone
• Seven Maestro flows written for a nightly Android emulator job, which is not passing yet

Design system

• One design token file in the W3C format, compiled into the theme module the app imports
• A custom Figma plugin builds the Figma library: variables with a Blush and an Amber mode, text styles, components and screens
• Barlow Condensed throughout, and a set of 60 icons

From the LifeOS repository, main branch, 4 October 2026. The test figures come from a full run of that commit.

Learnings

• Passing tests were not the same as a working screen. Several defects shipped with typecheck and unit tests green and were found only by rendering, so 375 tests mount real screens and a gate catches any new screen without one.
• Coverage was built in layers, each catching what the others could not: rendered screens, paired store tests across SQLite and memory, schema tests against real PostgreSQL, and structural gates that turn an invisible gap into a red test.
• No fix counted as proven until it was reverted and the test failed. That discipline exposed tests that could not tell the difference and guards that were never load-bearing.
• Some failures only a device shows. Each time one did, the test harness was made able to catch the next.
• Completion is reported screen by screen, after a design was recorded as shipped with half its screens unbuilt.