P—01 · DevelopmentProduction

Mito

Tasks, a timer, a semantic-zoom calendar and an AI mentor in one local-first app.

Role: Analysis, architecture, development with Claude Code
Period: 2026.09 → …
Status: Production
Stack: React · TypeScript · Zustand · Dexie / IndexedDB · Supabase · Node.js · LLM API · GitHub Actions

Interface

01 / 08

TodayThe home screen: the day at a glance, an hourly plan and the mentor’s morning briefing on where to start.

Problem

People who want to learn something new start on a wave of motivation — they draw up a schedule and keep notes — and drop it a few days later. Planning takes effort, and the plan and the time actually spent live in different places.

Solution

Mito brings tasks, a calendar (the plan) and a timer (the fact) into one app and shows how well the plan matched reality. Planning can be handed to an AI mentor — it proposes a schedule, and the user decides what to add.

A personal project where I am the customer, the analyst and the architect. The code was written with Claude Code following an 11-stage roadmap and an architecture decision log; every stage closed only after my review.

Goals

01Tasks, the plan and the actual time in one place
02Offline work and sync across devices
03A day plan in one click — but into the calendar only after confirmation

Features

Tasks with subtasks and smart listsQuick-add: #project, @tag, priority and estimate from one lineTimer and PomodoroSemantic-zoom calendar: from hours to a yearPlan vs actualStatistics on custom SVG chartsGuest mode and account syncAI mentor: day plan, chat, learning goalsRU / EN, light and dark themes

Key requirements

ID	Requirement	Priority
FR-01	Changes are saved on the device and are not lost offline.	Must
FR-02	An edit on one device appears on the others within seconds.	Must
FR-03	A user sees and changes only their own data.	Must
FR-04	The mentor's plan reaches the calendar only after confirmation.	Must
FR-05	If a model fails, the request goes to the next one.	Should
NFR-01	AI keys stay on the server; IP addresses are stored only as hashes.	Must
NFR-02	Mentor limits: 10 requests per minute and 60 per day per address, 800 per day overall.	Must
NFR-03	The browser talks only to the Mito domain.	Must
NFR-04	Deploy only after type checks, lint and tests pass.	Should

Scenarios

Signed-in userSync across devices

01Edits a task on the phone — the change is saved locally and queued
02After 0.8 s the queue goes to the server in one request
03The server keeps the version if it is newer
04The laptop gets a notification and pulls the changes

Guest or userDay plan from the AI mentor

01Clicks “Plan my day” and adds a wish
02The mentor server checks the limit and asks a model
03The server drops invalid blocks from the answer
04The user picks blocks — they land in the calendar

Timeline

2026.09Stages 0–4: foundationDesign system, IndexedDB data layer, tasks, timer, calendar.
2026.09Stages 5–6: zoom and analyticsA calendar with continuous zoom from day to year; plan vs actual; custom charts.
2026.09Stage 7: accounts and syncSupabase, change queue, server revisions, Realtime. First deploy to the VPS.
2026.09Stage 8: AI mentorOwn Node service, model chain, day plan, chat and briefing.
2026.10Stage 9: learning mentorGoals with stages, weekly reviews, knowledge checks, “Mentor” and “Assistant” modes.
NextStages 10–11PWA and performance, then Windows and Android with Tauri.

Challenges

Models make mistakes and invent thingsThe server validates the answer and drops blocks with wrong times or unknown tasks. The model sees tasks as refs t1, t2, and study days are enforced by code, not by the model.

Free-tier LLM limitsA chain Groq 120b → Groq 20b → Gemini Flash → Flash-Lite that switches on limits, overload or errors. The order is based on measurements.

The sync cursor must not skip changesRevisions are server-assigned, and one user's writes are serialised with an advisory lock, so revisions follow commit order.

Outcome

The app runs in production — guest mode, accounts with sync, an AI mentor on real models. 9 of 11 stages are done — about 20,000 lines of TypeScript and 160 automated tests.

Next — a PWA and desktop and mobile versions with Tauri.

Technologies

#React #TypeScript #Zustand #Dexie / IndexedDB #Supabase #Node.js #LLM API #GitHub Actions

§ 2.1

Components

Local-first — data lives in IndexedDB on the device and syncs in the background. The browser talks only to the Mito domain, and Caddy serves the app and proxies Supabase and the mentor server.

FIG. 01 — components

X 000 · Y 000

01
APPReact app. Data in IndexedDB, writes only through repositories, an outgoing change queue.
02
CADDYServes the app, proxies Supabase under /sb and the mentor under /api, sets X-Real-IP itself.
03
MENTORA Node service without database access: limits by IP hash, prompts, validation of model answers.
04
SUPABASEA records table with RLS, the push_records function, server revisions, Realtime.
05
LLMGroq 120b → Groq 20b → Gemini Flash → Flash-Lite, fallback on failure.
06
CI/CDChecks, database migrations, atomic release deploy to the VPS and a smoke test.

§ 2.2

Sync across devices

Participants

01 · APPSave locallyWrite to IndexedDB and the outbox queue. Works offline too.
02 · APPPush a batchAfter 0.8 s the edits go out in one push_records call.
03 · SUPABASECheck accessRLS: a user writes only their own rows.
04 · SUPABASELast-write-winsThe version with the later updatedAt wins; the revision grows.
05 · APPPull new changesRecords after the last revision are applied without echoing into the queue.
06 · OTHER DEVICERealtimeA notification — then the same pull.

§ 2.3

Day plan from the AI mentor

Participants

01 · USERPlan my dayToday or tomorrow, a wish of up to 500 characters.
02 · APPBuild contextTasks, a 4-day calendar, 2 weeks of stats. Tasks go as refs t1, t2.
03 · MENTORCheck the limit10 per minute and 60 per day per address; the address is stored only as a hash.
04 · LLMModel answerGroq → Gemini; on failure — the next model.
05 · MENTORValidate the answerDrop blocks with wrong times or unknown tasks.
06 · USERConfirmPick blocks — they land in the calendar with origin = mentor.

§ 2.4

Data model

Every entity has a UUIDv7, updatedAt and soft deletion via deletedAt — that is what sync relies on. TimeBlock is the plan and may overlap; TimeEntry is the fact — entries never overlap and at most one is running.

PROJECT4 f.

iduuidv7PK

nametext

colortint

orderint

TASK10 f.

iduuidv7PK

projectIduuidFK

parentIduuidFK

goalIduuidFK

titletext

statusenum

priority0..3

estimateMinint

plannedDatedate

dueDatedate

TIME_BLOCK6 f.

iduuidv7PK

taskIduuidFK

kindenum

starttimestamp

endtimestamp

originuser|mentor

TIME_ENTRY5 f.

iduuidv7PK

taskIduuidFK

starttimestamp

endtimestamp?

sourceenum

GOAL7 f.

iduuidv7PK

projectIduuidFK

titletext

statusenum

stagesjson

weeklyMinutesint

studyDaysint[]

MENTOR_NOTE4 f.

iduuidv7PK

goalIduuidFK

texttext

sourcementor|user

Relations · 7

PROJECT— 1 : N →TASK

TASK— 1 : N →TASK

TASK— 1 : N →TIME_BLOCK

TASK— 1 : N →TIME_ENTRY

GOAL— 1 : N →TASK

GOAL— 1 : N →MENTOR_NOTE

PROJECT— 1 : 0..1 →GOAL

§ 2.5

API and integrations

POST/sb/rest/v1/rpc/push_recordsPush a batch of changes (up to 200); only newer versions are kept
GET/sb/rest/v1/records?rev=gt.{N}Changes after revision N (up to 500)
POST/api/mentorMentor request: plan, chat, brief, intake, roadmap, coach
GET/api/mentor/healthWhich model providers are available

Supabase CloudHTTPS via the /sb proxyPostgreSQL with RLS, Auth, Realtime notifications to other devices.
Groq → GeminiOpenAI-compatible APIProvider chain with automatic fallback; keys stay on the server.
GitHub Actions → VPSSSH · rsyncChecks → migrations → atomic release switch → smoke test.

§ 2.6

Key decisions

Decision 01

Local-first on IndexedDB

Choice: Data lives on the device first; the server is only for sync.
Rationale: The app works offline and responds instantly, and a guest needs no account.
Alternatives: Classic client-server — simpler, but useless offline.

Decision 02

One records table with jsonb

Choice: All entities are rows of one table with sync fields.
Rationale: One cursor and one Realtime subscription; the client evolves documents without server migrations.
Alternatives: A table per entity — more migrations and subscriptions.

Decision 03

Last-write-wins instead of picking a version

+ Pros: Simple, no extra questions for the user
− Trade-offs: Time comes from the device clock; Edits in the same millisecond diverge (rare)

Decision 04

Mentor without database access

Choice: The app builds the data summary with its analytics core and sends it with the request.
Rationale: Data is local-first — guests have none on the server, and the server holds less personal data.

Decision 05

Confirmation before writing to the calendar

Choice: The plan is shown first; the user picks the blocks.
Rationale: A model can be wrong and the calendar is personal space — an extra click is cheaper than lost trust.

Next · P—02TechRent