My CRM Is a Folder of Markdown Files. Today I Open-Sourced It

This is an adapted English version. Original (Russian): automata.sale/blog/ai-automation/automata-crm-open-source/

My CRM Is a Folder of Markdown Files. Today I Open-Sourced It

My CRM weighs a couple of gigabytes, sits in a folder on my laptop, and consists of plain Markdown files. No database. No vendor web UI. No “export to CSV, if you’re lucky”. Today I released its engine as open source: github.com/eudigitaldotru/crm.automata.sale. Here is why I built it this way, and why I am giving it away.

I got tired of SaaS CRMs

I am a 1C-Bitrix integrator, working solo since 2012. My clients are small B2B sites: roofing, sandwich panels, private clinics. The communication loop looks typical: Telegram in a dozen chats, email in three inboxes, the MAX messenger, phone calls. A deal lives everywhere at once and nowhere in full.

I tried keeping it in a spreadsheet. Then in a SaaS CRM. Both times I hit the same wall: for a CRM to reflect reality, someone has to enter data by hand. By hand means it does not get entered. And when your business runs in Russian messengers, off-the-shelf CRMs get weird: wrong fields, crooked exports, a bill that grows every year.

So I made a move that would have looked strange in 2012 and turned out to be the obvious one in 2026: I stopped thinking of a CRM as a program. A CRM is data. So the data should live in a shape any tool can chew, AI included.

A CRM that lives in Markdown

My entire client base is a 10_Clients/ folder, one Markdown card per client: contacts, contracts, service history. Invoices are 30_Invoices/, also files. Chats, tasks, leads, tickets, same story.

What this buys in practice:

  • Data outlives everything. Files stay readable in any editor ten years from now. I can find every client with an overdue act with one grep. Every change an agent makes shows up as a git diff.
  • No vendor lock-in. Subscription ends, service shuts down, prices double, the folder stays. Obsidian even opens it, turning the CRM into a knowledge base with graphs and backlinks.
  • AI can work with it directly. And that is the whole point.

AI agents are the CRM operators

This is what it was all for. Files plus scripts is the habitat where a coding agent (ZCode, Claude Code, or any compatible CLI) feels at home. I do not need “AI features” bolted onto an interface: the agent simply reads and writes the same files I do.

In the morning I say: “Triage the inbox, invoice the debtors, remind the client about the September act.” The agent reads the cards, runs the scripts, creates invoice files, attaches PDFs, and reports back with a list. I review the diff and say ok. Delivery then goes out through the configured channels.

This is not a “coming soon” slide. This loop runs my real business every day: Telegram leads become leads on their own, invoices go out on their own, I only handle what genuinely needs a human.

One inbox: Telegram, MAX, email

The communication side works like this: a tiny Telethon gateway pipes my personal Telegram account into the CRM (personal, not a bot, so group chats where bots are banned still show up). Email arrives over IMAP from several mailboxes. MAX connects via a bot.

Everything merges into a single inbound stream. Known senders are matched to client cards by phone and handle. Unknown senders become leads with a drafted card. On the dashboard it is one thread feed with three columns: the dialog, the client card, health.

Money: invoices, acts, auto-reconciliation

I judge a CRM’s money story by one question: how many actions does it take to send an invoice. Here it is one command, or one sentence to the agent.

A generator produces PDF invoices and acceptance acts from templates. A Tochka Bank open-API integration creates bills, tracks payment status and delivers documents to the client. Payments reconcile against the bank statement automatically, every morning. Overdue invoices light up before they become a problem.

Sites under watch

As an integrator I host other people’s sites, so monitoring is built in: uptime, SSL certificate and domain expiry alerts, PageSpeed, and GEO audits that check whether a site is visible not just to Google but to the LLMs that now answer “where do I buy roofing” for my clients’ customers.

A client’s domain expiring in two weeks triggers an email and a ticket by itself, without me.

Secure by default

The part I am separately proud of: a sec_guard module. Every outbound request from the engine goes through it: http/https only, DNS resolution with private ranges and cloud metadata endpoints blocked, every redirect hop re-validated, file operations contained inside the vault.

That is not theory: the module was born from a real audit, after I ran my own code through a static analyzer and fixed everything it found. The repository keeps the same discipline: zero hardcoded secrets, everything through environment variables, data never enters git.

What is inside and how to try it

The public repo holds 190 files: a Python/FastAPI engine, a Vite dashboard, the Telegram gateway, migrations, document templates with placeholders. MIT licensed. There is a README in English and Russian, an install script, and one-command updates that never touch your data folders.

git clone https://github.com/eudigitaldotru/crm.automata.sale.git
cd crm.automata.sale
./install.sh && ./start.sh

From there, the README covers the unified inbox, invoicing, monitoring and agents. The dashboard UI is Russian for now, i18n is on the roadmap.

Why give it away

The honest answer: because it pays me back. I earn on integration and support, and code reviewed by other eyes becomes better than mine. Every GitHub star is a signal that systems like this are needed. Every issue is a free audit.

But there is a taller reason too. Software is becoming personal again: your own machine, your own files, your own agent working for you instead of a vendor. I think that is where small teams are heading. Now anyone who thinks so has a working starting point.

A star on GitHub is the best way to say thanks.