Ordovia — Product & Systems Architecture

CTX-01

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.

PRB-01

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.

ROL-01

My role

Product architecture
Systems architecture
Frontend / backend integration
Synchronization and release operations

SOL-01

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.

BLD-01

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

ARC-01

System architecture

Platform architecture

React / TypeScript
Web → Cloudflare
Android → Capacitor
iOS → Capacitor foundation
Windows → Tauri / Rust
Domain Services
Supabase / PostgreSQL
Auth · RLS · RPC · Storage

STK-01

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

DEC-01

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-01

Code / architecture excerpts

Product architecture summaryTS

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;

FLOW-01

Data flow

User action
Domain service
Optimistic UI / query cache
Supabase RPC / tables
RLS + persistence
Realtime / refresh
Synchronized clients

RISK-01

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

OUT-01

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.

LRN-01

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

Visit product