Ordovia
PERSONAL DAILY COMMAND CENTER
A multi-platform personal system that brings tasks, notes, habits, planning, projects, rituals and personal knowledge into one daily command center.
Before the technical detail, read the problem, decision and evidence as one narrative chain.
- STATUS
- Live · continuously developed
- TYPE
- Product · Productivity / PKM
- ROLE
- Product architecture · Systems architecture
- PLATFORMS
- Web · Android · iOS foundation · Windows
What was the problem, what changed, what is different now?
Before the technology details, this shows the transformation: the original bottleneck, the intervention, and the outcome that can be verified today.
PROBLEM
Tasks, notes, rituals, planning, calendar data and the knowledge graph all have different data models. The same account and source of truth also has to remain reliable across web, mobile and desktop.
INTERVENTION
I built one shared web product layer around common domain services, centralized ownership and synchronization rules on Supabase/PostgreSQL, then separated delivery through Cloudflare, Capacitor and Tauri.
OUTCOME / CURRENT STATE
Ordovia is a living product shipped on web and Android, with a Windows delivery path and iOS foundation. This case study focuses less on isolated features and more on the architecture that lets the system keep growing.
- EVD-03 / Windows release
- Microsoft Store · 9NTKLRQFCM8W Microsoft Store product ID
- EVD-04 / System outcome
- One account · shared data authority · multiple platforms Case evidence
ROI, revenue lift or percentages are shown only when a verifiable source exists. Otherwise the proof is the working product, distribution, system outcome and sourceable scope — never invented metrics.
Week-1 retained command users
Share of users who complete an initial core command action, return the following week and complete at least one core task / ritual / note action again.
Activation cohort → following-week return → core command action.
Product event stream; the PostHog / Amplitude observability surfaces verified in the case stack can serve as the event source for this metric.
No verified baseline is published for this case yet; no value is invented and no numerical claim is made before the source is verified.
Context
Ordovia was not built to become another todo app. The goal was to make several productivity domains behave coherently under the same user, day and synchronization model.
Problem
Tasks, notes, rituals, planning, calendar data and the knowledge graph all have different data models. The same account and source of truth also has to remain reliable across web, mobile and desktop.
My role
- Product architecture
- Systems architecture
- Frontend / backend integration
- Synchronization and release operations
Solution
I built one shared web product layer around common domain services, centralized ownership and synchronization rules on Supabase/PostgreSQL, then separated delivery through Cloudflare, Capacitor and Tauri.
What was built
- Shared product architecture for tasks, notes, habits, rituals, library and planning
- Cloud-authoritative synchronization and session continuity
- Supabase RLS, RPCs and user-level data ownership
- Google Calendar integration
- Markdown, wikilinks and knowledge graph layer
- PWA, notifications, deep links and platform packaging
- Paddle / Adapty entitlement and subscription model
System architecture
Technical stack
FRONTEND
React · TypeScript · Vite · React Router · TanStack Query · Zustand · Radix UI · Milkdown · Framer Motion
BACKEND
Supabase · PostgreSQL · RLS · RPC
INFRASTRUCTURE
Cloudflare · R2
PLATFORM
Capacitor · Tauri · Rust
OBSERVABILITY / TEST
Sentry · PostHog · Amplitude · Vitest · Playwright
BILLING
Paddle · Adapty
Important engineering decisions
- Treat the cloud as authoritative and clients as synchronized surfaces
- Package the shared web layer instead of maintaining separate Android and Windows product codebases
- Encode data ownership at the RLS layer instead of trusting UI logic
- Attach new modules to the shared daily-command model instead of creating isolated islands
Code / architecture excerpts
01const ordovia = {02 frontend: ["React", "TypeScript", "Vite"],03 data: ["Supabase", "PostgreSQL", "RLS"],04 edge: ["Cloudflare", "R2"],05 mobile: "Capacitor",06 desktop: "Tauri",07 model: "cloud-authoritative",08} satisfies ProductArchitecture;Data flow
Challenges and constraints
- Synchronization and identity consistency across many domains
- Maintaining the same behavior across web, Android and Windows
- Containing performance, entitlement and auth regressions as the product grows
Result / current state
Ordovia is a living product shipped on web and Android, with a Windows delivery path and iOS foundation. This case study focuses less on isolated features and more on the architecture that lets the system keep growing.
Engineering takeaways
- In multi-module products, domain boundaries matter more than individual screens.
- Synchronization should be architectural, not an afterthought added after the product grows.
- A shared codebase only creates leverage when platform differences are deliberately bounded.
OUT-LIVE / VISIT PRODUCT
Ordovia
EVIDENCE / AUTHORITY
What does this case prove?
The roles and decisions documented here are not portfolio decoration; they are concrete evidence for the work described on the services and capabilities pages.
NEXT PROJECT
PRJ-02Feedcrumb