--- title: "Own your company memory: plain markdown in a git repo, no lock-in" slug: "own-your-company-memory" dek: "A tool is only local-first if your company's memory still opens in a plain text editor after the company that built the tool is gone." audience: "Solo founders and small teams deciding where their company's operating memory should live for the long run." tags: [local-first, data-ownership, git, markdown, no-lock-in] --- ## The question people keep asking each other A founder posted a plain question on [r/Notion](https://www.reddit.com/r/Notion/comments/1ndedvc/): does anyone else feel uncomfortable with how much they hold. 57 people answered. Nobody in the thread argued about features. They described the same low-grade worry, in different words: years of company knowledge sitting inside one company's database, reachable only through one company's app, priced however that company decides to price it next quarter. A second thread in the same subreddit asks the blunter, practical version of the same question: [why can't I export my Notion data properly](https://www.reddit.com/r/Notion/comments/1uladm0/). That's the part that actually matters. Putting data into a tool is easy. The real test is what comes back out when you try to leave, and whether what comes out is still usable or just a pile of files you now have to reverse-engineer by hand. None of this is unique to Notion. It's the shape of every workspace tool built on a proprietary format — Notion, Evernote, Coda, the rest of the category. You don't find out how locked in you are until the day you try to leave, or the day the vendor makes that decision for you. ## "Local-first" only means one thing There's a live engineering argument about this, and it converges on one useful test. A commenter on a recent [Hacker News thread about local-first software](https://news.ycombinator.com/item?id=45333526) said it as plainly as it can be said: > If it doesn't work if the app developer shuts down the servers, it's not local-first. That's the whole bar. Not "can I export it." Not "is there an API." Can you turn off the company and still read your own data, with tools that will exist regardless of whether that company does. Most export features fail this test, because export is a lossy conversion happening at the edge of a system whose real structure lives in a proprietary database. The database is the source of truth. The export is a courtesy copy, generated on request, in whatever shape the vendor decided to support this year. ## What Lycato actually stores Lycato inverts that relationship. There's no proprietary database sitting behind an export button, because there's no export button — there's nothing to export. The plain markdown files in a git repo are the source of truth, not a courtesy copy of one. One git repo per company holds all of it: people and CRM, money (ledger, runway, reconciliation), the decisions log, obligations and compliance deadlines, investor updates, KPI snapshots, the inbox, the content queue, a basic cap table. It's markdown, in folders, versioned by git. A `lycato` CLI and a local web Cockpit render it, and adapters pull in data from Mercury, GitHub, Stripe, and Plain. But the Cockpit is a view onto the repo. The repo is the database. That distinction is what the review workflow is built on. When an AI agent wants to update something, it doesn't write to a database you can't see — it proposes the change as a git diff: ```diff --- a/people/jane-doe.md +++ b/people/jane-doe.md @@ -4,3 +4,6 @@ role: Angel investor last_contact: 2026-05-02 --- + +## 2026-07-06 +Replied to the intro email. Wants a call before month-end re: the bridge. ``` You read the diff — in Cockpit's Review surface, or straight in git, it makes no difference which — and you merge it, or you don't. Nothing ships unreviewed. That's a governance feature first, but it's a data-ownership feature too: the format the agent writes in is the same format `cat` reads, the same format `git log` shows history in, the same format that opens in any text editor on any machine, indefinitely, whether or not Lycato the company still exists to render it for you. ## The actual test, and what it doesn't cover Run this test on any tool you're evaluating, Lycato included: assume the vendor is gone tomorrow, no warning, no export window. Can you still get to your data, in a form you can read and grep, without that vendor's software running anywhere? For a `lycato` repo, the answer doesn't depend on Lycato's fate, because `git clone` and a text editor were never Lycato's to take away in the first place. That's not a claim that Lycato removes every dependency, and it shouldn't be read as one. The adapters that sync Mercury, Stripe, GitHub, and Plain into your repo are still talking to those companies' APIs — if one of them cuts off access, that particular sync stops, same as any integration would. What doesn't stop is your own historical record: every balance, every KPI snapshot, every decision already pulled into markdown stays in your repo, readable, regardless of what any of those vendors do next. Self-hosting is also a real responsibility, not a free convenience — AGPL-3.0 and a plain-text substrate mean you can always run it yourself, but "always can" also means the backups and the hosting are now genuinely yours to manage, not a line item on someone else's SLA. ## Takeaway Before you trust a tool with your company's memory, ask it the only question that matters: what happens the day you stop paying, or the day the company behind it is gone. If the honest answer involves an export button, a support ticket, and hoping the formatting survives, you already know where that leads — the same place those 57 answers on r/Notion came from. If the answer is "clone the repo, open the folder, everything is still there, unchanged," you're not trusting the vendor. You're just using their tool for as long as it earns that, and not a day longer.