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; about 1,960 tests on every change; a release APK in CI.

   Challenges

   iOS has never been compiled, so cross-platform is unproven; intake recording is built 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 or domain is established.

What exists today

• 7life categories
• 2themes, one component set
• 19server migrations in CI
• ~1,960tests on every change
• 3required checks on main

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, each with a catalogue-written reason

Engineering foundation

• Supabase backend in the EU region
• Custom sync through an Edge Function, validated against the same contract package the client uses
• GitHub repository; main protected behind three required checks
• Nineteen server migrations run in CI against real PostgreSQL
• Local store held to identical behaviour across SQLite and memory by paired tests
• Every screen rendered by a test or listed as not; roughly 1,960 tests on every change
• A release APK builds in CI

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

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 every screen is now rendered by a test, roughly 355 of them.
• 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.