01 · Origin
I was losing commitments inside the system meant to organize them.
When I became a product manager, the volume of decisions, follow-ups, and context I carried grew faster than my personal system. I used a custom Notion template for daily notes and manually moved unfinished items from one day to the next. Tasks were easy to leave behind, and the reasoning behind them became detached from the work itself.
I spoke with roughly ten colleagues, friends, and technically minded people about their workflows. Everyone had assembled a different mix of notes, task managers, calendars, local language models, and sync services. A meaningful minority had abandoned productivity systems because maintaining several tools created more work than clarity.
What if the system carried unfinished work forward automatically—and kept the context beside the task?
02 · First product
Start with one promise: unfinished work does not disappear.
The first web version was deliberately narrow. Today held immediate work, Someday held the backlog, and Timeline held future commitments. At midnight, unfinished tasks rolled forward. A manual End Day action provided closure and an undo path.
I shared early builds with a few colleagues for usability feedback and bug discovery. The response was positive, but requests expanded almost immediately. Mobile access was the loudest need, so I turned Rollo into a progressive web app installable on desktop and mobile.

03 · Pivot
Local files changed from storage into an interface for AI.
As Claude Code and local-file workflows emerged, I saw a behavioral shift. People could let an AI work directly with their knowledge while keeping private files on their own machines. The cloud architecture of the web application could not deliver that model convincingly.
I chose to restart rather than port. The new Rollo would be a native app for Windows, macOS, iOS, and Android, built around clean Markdown files and inspired by Obsidian’s ownership model. Its purpose was more ambitious: turn stored knowledge into work that could be planned, completed, and acted on by people or agents.
Obsidian stores your knowledge. Rollo deploys it.
A local-first core with one guarded AI tool layer.
The map separates user-owned knowledge, on-device product logic, and synchronized task state. Select a layer to inspect the product promise, implementation, and boundary behind it.
Several AI runtimes, one controlled path into the product.
- Product promise
- Native AI, Codex, Claude, and other compatible agents can retrieve context, plan work, and propose changes without receiving unrestricted access to the vault.
- How it works
- One VaultToolService backs Rollo’s native workflows, the loopback MCP server for outside clients, and the ACP host that embeds bring-your-own agents inside Rollo’s chat.
- Boundary
- MCP is localhost-only with bearer-token authentication. Agent writes remain reviewable, and ACP does not expose the raw vault as its working directory.
The files stay useful without Rollo.
- Product promise
- Notes remain ordinary Markdown that can be read and edited in Obsidian, VS Code, or any other compatible tool.
- How it works
- VaultService reads and watches a local folder. Dropbox, iCloud Drive, Google Drive, or OneDrive can sync that folder between devices; Rollo does not replace them with proprietary content sync.
- Boundary
- The local file is the source of truth for note content, and reading or editing notes keeps working offline.
Rollo adds structure without polluting the notes.
- Product promise
- A hidden sidecar gives selected blocks durable task identity while the visible Markdown stays clean.
- How it works
- The .rollo sidecar stores task-source locators. Local SQLite maintains wikilinks, FTS5 search, the task cache, and queued offline mutations; the file watcher reindexes changes incrementally.
- Boundary
- If an external edit makes a source match uncertain, Rollo marks it for review instead of attaching a task to a guessed block.
One identity connects a note block to planned work.
- Product promise
- A block can become a task without losing its source, and a planner task can remain connected to the context that created it.
- How it works
- Block-to-task promotion records the source in the sidecar, updates the local task cache, and synchronizes task state. Status and planning changes patch the source when it can be resolved confidently.
- Boundary
- Offline mutations queue locally, while unfinished Today tasks roll forward on-device and reconcile when connectivity returns.
The server synchronizes task state, not the vault.
- Product promise
- Status, priority, dates, and identity can follow the user across devices while their knowledge base remains file-owned.
- How it works
- Supabase provides authentication, Postgres task records, row-level security, and Realtime updates. Drift keeps a local cache so the planner can continue to work offline.
- Boundary
- The server is authoritative for task state; it does not become the source of truth or the sync provider for the user’s vault files.
Several AI runtimes, one controlled path into the product.
- Product promise
- Native AI, Codex, Claude, and other compatible agents can retrieve context, plan work, and propose changes without receiving unrestricted access to the vault.
- How it works
- One VaultToolService backs Rollo’s native workflows, the loopback MCP server for outside clients, and the ACP host that embeds bring-your-own agents inside Rollo’s chat.
- Boundary
- MCP is localhost-only with bearer-token authentication. Agent writes remain reviewable, and ACP does not expose the raw vault as its working directory.
The backend synchronized work, not the vault.
Supabase handled identity and shared task state—including recurrence, context snapshots, and queued offline mutations. The Markdown vault remained outside that schema and under the user’s control.

04 · Product system
One loop connected knowledge, planning, and AI execution.
The defining constraint was that every task should remain connected to knowledge. A note block could become a task in one action. A task made inside the planner became a real checkbox inside a daily Markdown note. There was only one task model, regardless of where work began.
AI could work inside the product—not beside it.
Rollo gave native and external agents the same controlled access to the vault and planner. They could retrieve context, turn notes into structured work, and propose changes without receiving an unrestricted path to the user’s files.
Plan the day, break down broad tasks, and review overloaded plans through suggestions the user approves before Rollo changes anything.
Agents could search and read the vault, inspect planning context, create block-anchored tasks, and update existing work.
Rollo supported native AI, Codex, MCP clients, and ACP-hosted agents while keeping proposed file changes visible for review.
Keep Markdown clean.
Files remained readable in Obsidian, VS Code, and other tools. Rollo stored durable task links in a hidden sidecar and surfaced ambiguous source matches instead of silently guessing.
Build once for four platforms.
Flutter and Dart provided one application architecture for Windows, macOS, iOS, and Android. Supabase handled identity and synchronized task state while the vault remained locally owned.
Do not lock the product to one model.
Native AI, Codex, external MCP clients, and ACP-hosted agents used the same vault and planner contract. Users could bring their preferred runtime without creating a second, less controlled path to their knowledge.
The vault stayed readable—and became explorable.
Free-text search retrieved matching passages across the vault. Graph filters reduced a large knowledge base to a subject, while selecting a node exposed the files connected to it. Notes remained ordinary Markdown with source and rendered views available together.

What reached the beta build
A broad product, built end to end.
- Block editor, local vault, wikilinks, backlinks, and search
- Today, Someday, recurring work, rollover, and calendar
- Priority matrix and Kanban-style progress views
- Knowledge graph and source-integrity review
- Focused AI workflows: Plan My Day, Break Down Task, and Review & Clean Up
- Native AI and Codex connections with contextual vault and planner tools
- External-agent interoperability through local MCP and ACP hosting
- PostHog analytics, automated QA, CI/CD, and desktop updates
Build evidence
Repository evidence establishes implementation and beta preparation. The native build was not distributed to external testers.
05 · The decision
I mistook the ability to keep building for evidence that I should.
The native application worked, but I postponed distribution. Android had only been tested through an emulator, and desktop distribution introduced developer-account, signing, and trust requirements before I knew whether anyone would use the product. I decided to polish first.
That decision created the wrong loop. I kept improving UX and adding capabilities from competitive research while avoiding the question that mattered: did the product solve a common problem better enough to earn a place in someone else’s workflow?
At the same time, Claude, Codex, and other agentic tools gained direct access to many file formats. Users could assemble personal workflows, automations, and interfaces around their existing habits instead of adopting Rollo’s standardized system. I concluded that the opportunity no longer justified continued investment and stopped development.
06 · What changed in me
Rollo expanded what I can build—and changed when I choose to build.
Technical fluency became practical.
I moved beyond web applications into Flutter, Dart, native filesystem behavior, Supabase, PostHog, cross-platform release systems, MCP, ACP, and automated end-to-end QA.
Architecture is product design.
Clean Markdown, sidecar identity, block-anchored tasks, local retrieval, and controlled agent tools were user promises expressed as technical decisions.
Validation must constrain possibility.
Knowing the principle was not enough. My next products start with the narrowest valuable problem, reach the target audience early, and earn the next iteration through evidence.
The most important thing I shipped was better judgment: being able to build almost anything does not make everything worth building.






