Building Ayumi and Kitae: Local-First Apps for Myself
/ 4 min read
Table of Contents
I have recently been building two apps for myself: Ayumi, a journaling app, and Kitae, a workout tracker.
They solve different problems, but they come from the same idea. I want small, local-first tools that I can start using without creating an account, signing in with a social provider, or sending all of my personal history to an application backend. I also want the data to remain useful outside the app itself.
For both apps, Markdown is an important part of that design.
Two Apps, One Direction
Ayumi is a journal for macOS and iOS. Journal entries are stored as Markdown files, so they can live in a folder I choose and work naturally with tools such as Obsidian.
Kitae is an iOS app for recording strength training. It handles the practical details I want during a workout, such as exercises, sets, weights, repetitions, RPE, and rest timing. Its Markdown synchronization can mirror each workout as a file and import edits or new plans from the same folder.
Neither app requires social login. I can open the app and begin using it. That sounds like a small detail, but it changes the relationship between the app and its data. The app is not the owner of my history. It is one interface for working with it.
Markdown as an Interface
I did not choose Markdown only because it is easy to read. I chose it because it is a durable, open interface between different tools.
A journal entry or workout log should not become inaccessible when an app changes direction or disappears. A Markdown file can be opened in a text editor, searched with command-line tools, versioned, backed up, or moved into another system. The format is simple enough to inspect directly and structured enough to support metadata and automation.
It is also a convenient interface for AI agents.
I designed Ayumi and Kitae with the assumption that I would use their data from Codex and Claude. An agent can read a directory of journal entries, find relevant context, and help me reflect on a pattern. It can inspect previous workouts and draft a future training plan. With Kitae, a plan written in the expected Markdown format can be imported back into the app.
This is different from adding an AI chat screen to every product. The apps remain focused on recording and browsing. Codex and Claude operate on the files through the workflows I choose. Markdown becomes a small, practical protocol shared by me, the apps, and the agents.
The Local-First Boundary in Ayumi
Ayumi has one important exception to the local-first story: voice transcription uses Google’s Gemini API. It would therefore be inaccurate to call the entire workflow completely local.
I chose Gemini because its transcription quality works well for me. More importantly, I can provide context while requesting a transcription. Supplying relevant names, vocabulary, or background makes the result more accurate than treating the audio as an isolated recording. Because Gemini accepts prompts, I can also ask it to clean up or structure the transcription as part of the same workflow.
Ayumi uses a BYOK—bring your own key—model. The app does not send audio through an Ayumi-operated backend, and I do not run a service that stores users’ journals, recordings, or API keys. The app communicates directly with Google using the key supplied by the user.
That distinction matters to me. Local-first does not have to mean pretending that network services never exist. It can mean making the boundary explicit: which operation leaves the device, why it does so, who receives it, and what the app itself does not retain.
Why I Built Them
Before Ayumi and Kitae, I used paid apps for journaling and workout tracking. They were useful, and using them taught me what I actually needed. Over time, however, small preferences accumulated.
I wanted the data in a format I could inspect. I wanted to decide where it lived. I wanted to use it from Codex and Claude without waiting for an official integration or exporting it through a special workflow. I wanted screens and interactions shaped around how I journal and train, rather than around the average user or the business model of a general-purpose product.
Eventually, the desire to change these tools became stronger than the convenience of continuing to adapt myself to them. Modern AI-assisted development made it realistic to turn those preferences into working software. I could finally build the journal and workout tracker I had gradually specified simply by using other apps for long enough.
Ayumi and Kitae are personal software in the literal sense. They are not attempts to invent new categories. They are tools made around my own habits, with files I can keep, understand, and use elsewhere.
That is the part I find most exciting: software no longer has to be a service I subscribe to and accommodate. It can be something I shape around the way I already live.