Product and business context
The product began as a narrow web tool that automatically rolled unfinished tasks forward. Early feedback quickly expanded the demand toward mobile access, notes, planning, and connected knowledge.
The rise of local-file AI workflows created a stronger proposition: make stored knowledge actionable without moving ownership of the vault into a proprietary cloud.
My role and decision scope
One builder owned the complete product system.
I conceived the product, researched the problem, designed the interaction model, chose the architecture, wrote the production code, built automated tests and release workflows, and prepared the native application for beta.
- Product strategy
- UX and interaction design
- Architecture and implementation
- Quality and release readiness
The problem
Knowledge systems stored context, task managers stored commitments, and AI worked beside both instead of safely inside one loop.
Work became detached from the notes and reasoning that created it. At the same time, giving agents unrestricted file access weakened control and made changes difficult to review.
Rollo needed one task model across notes and planning, clean local files, controlled agent tools, and a credible path across desktop and mobile platforms.
Three important decisions
The choices that most clearly show the product judgment behind the work.
- 01
Restart around local files instead of porting the web product.
Claude Code and local-file workflows changed the opportunity. I rebuilt Rollo as a native product where Markdown stayed user-owned and became a safe interface for AI-assisted work.
Architecture should express the user promise. - 02
Keep knowledge local while synchronizing task state.
The vault remained ordinary Markdown. A sidecar preserved identity and links, while Supabase synchronized shared task state, recurrence, context snapshots, and offline mutations.
Synchronize work without taking ownership of the vault. - 03
Stop when build velocity outran validation.
The beta worked, but I postponed distribution while agentic tools rapidly made standardized second-brain workflows less differentiated. I stopped rather than keep polishing a weakening opportunity.
The ability to keep building is not evidence that I should.
What shipped
- A Flutter application targeting Windows, macOS, iOS, and Android
- A local Markdown vault with block editing, wikilinks, backlinks, search, and graph views
- Today, Someday, rollover, recurring work, calendar, priority matrix, and Kanban views
- Native AI workflows for planning, task breakdown, and reviewable changes
- Codex, MCP, and ACP integrations using the same controlled planner and vault tools
- PostHog analytics, automated QA, CI/CD, desktop updates, and a 0.1.0 beta build
Results and evidence
- 4
- target platforms from one codebase
- 384
- native-product commits in three months
- 184
- test files in the native repository
- 0.1.0
- beta build prepared for distribution
Repository evidence establishes implementation and beta preparation. The native build was not distributed to external testers.
What I learned
Validation must constrain possibility, especially when building becomes unusually fast.
Rollo gave me practical fluency across native application development, local-first architecture, Supabase, agent protocols, release systems, and automated QA.
More importantly, it changed my sequencing: reach the target audience earlier, define the narrowest valuable problem, and make every next iteration earn its investment through evidence.
Want the decisions, flows, and evidence in detail?
The full case contains the complete product story, supporting visuals, and the reasoning behind the work.