Follow the Build
I’m building a local-first system that helps me think, organize decisions, maintain context, and reduce operational friction without handing control over to AI.
The Architecture
The tooling
The failures
The tradeoffs
Why I’m Building This
Most software assumes one of two things:
Either:
- humans should adapt themselves to applications
Or:
- AI should automate everything
I don’t think either model is sufficient.
I want systems that:
- preserve judgment
- reduce repetitive friction
- maintain long-term context
- help with reasoning and coordination
- remain inspectable and portable
- and fail safely
That means:
- local-first storage
- Markdown as a core format
- explicit permissions
- deterministic execution
- constrained automation
- AI used selectively, where it genuinely helps
Not AI everywhere.
Not “agents” running unchecked.
Not replacing thinking with prompts.
The goal is narrower and more practical:
Build systems that help humans operate more effectively without surrendering visibility or control.
Current Principles
Local-first
The core system should continue functioning even if external services disappear.
Portable formats matter.
Human-readable formats matter.
Markdown is the current foundation because it is simple, durable, inspectable, and difficult to lock away.
AI Proposes; Systems Execute
AI is useful for:
- synthesis
- summarization
- pattern recognition
- drafting
- exploratory reasoning
It is much less trustworthy for:
- commitments
- financial decisions
- uncontrolled automation
- irreversible actions
High-risk actions require:
- explicit constraints
- deterministic tooling
- approval layers
- clear visibility into what is happening
Existing Apps Are Not the Enemy
I’m not trying to replace every application with one giant AI layer.
The system should sit above existing tools:
- calendars
- notes
- documents
- publishing platforms
- financial tools
- communication systems
The objective is coordination and context, not total replacement.
Simplicity Compounds
One of the easiest ways to destroy a system is to overbuild it too early.
A large portion of this project is figuring out:
- what deserves AI
- what should remain deterministic
- what should remain manual
- and where complexity quietly becomes fragility
Follow the Build
Most of this is being figured out in public, in real time.
You can follow along through:
- the newsletter
- field notes
- videos
- architecture breakdowns
- experiments
- and ongoing implementation work
Because the interesting part is not the final system.
It’s learning what survives contact with reality.