Can You Build a CRM Entirely in Markdown?
Short answer? Yes.
Long answer? Yes...but only if you stop thinking about Markdown as documents and start thinking about it as data.
For years I've accepted that CRM software has to look a "certain way".
- A database.
- A web application.
- A backend.
- Authentication.
- A cloud subscription.
- Probably another tab that's permanently open in your favorite browser.
Contacts live in tables. Companies live in tables. Meetings live in tables.Tasks live in tables.
Everything eventually becomes another row in another SQL database.
I know, this is not really 100% the case nowadays, but I'm pretty sure we can agree that, at a higher corporate level, this has been the case nine times out of ten.
But here's my question.
What if every one of those rows was just...a Markdown file?
For many, that sounds ridiculous at first... until you realize that databases and Markdown aren't actually solving different problems.
They're storing structured information. The difference is that databases hide the structure. And Markdown lets you own it.
Markdown isn't the limitation.
Treating Markdown like text files is.
A CRM isn't a collection of paragraphs. It's a collection of entities:
- People
- Accounts
- Meetings
- Deals
- Projects
- Tasks
- Emails
- Documents
Each entity simply has properties and relationships. That's it.
Take a contact:
---
id: victoria-smith
type: contact
name: Victoria Smith
company: [[globex]]
owner: [[me]]
status: active
email: victoria@globex.com
phone: +1 555 123 4567
last-contact: 2026-06-28
---
That's already a database row. Bang.
Except... it's also a perfectly readable document. Double bang.
Relationships become links
Traditional CRMs store foreign keys.
company_id = 42
Nobody enjoys reading that.
Markdown gives you something humans can actually understand.
company: [[globex]]
owner: [[me]]
Those aren't just pretty links. They're relationships.
The Yamlink graph can traverse them.
Queries can use them.
Visual graphs can render them.
Exactly the same information.
Far nicer representation.
Your filesystem becomes the database
Imagine opening your CRM.
Except your CRM is...
CRM/
accounts/
contacts/
meetings/
projects/
deals/
tasks/
Every file can be opened in VS Code.
Every file works in Git.
Every file survives twenty years.
No vendor lock-in. No export button. No proprietary binary format. No "contact limit." No "premium tier."
It's just files.
"But where are the tables?"
Everyone asks me this.
Ironically, the tables are the easiest part.
Once every note follows a schema (any schema), tables become generated views.
Show all active contacts.
!view contact
where status = active
sort company
Show every meeting with Globex.
!view meeting
where account = [[globex]]
sort date desc
Show deals closing this month.
!view deal
where close-date <= end-of-month()
You never manually build the table.
The table is simply another projection of the vault.
A CRM is mostly relationships
Here's where things become interesting.
- Victoria belongs to Globex.
- Victoria attended Meeting A.
- Meeting A produced Opportunity X.
- Opportunity X generated Proposal B.
- Proposal B became Project C.
Traditional CRMs hide that chain behind different screens. A graph doesn't.
Victoria
↓
Globex
↓
Quarterly Review
↓
Migration Project
↓
Implementation
You can literally traverse your business.
Frontmatter is your schema
This is the part people underestimate.
Consistency matters more than complexity.
A contact always has:
type: contact
company:
owner:
status:
email:
phone:
An account always has:
type: account
industry:
owner:
size:
website:
A meeting always has:
type: meeting
date:
participants:
account:
outcome:
That's your schema.
Nothing magical.
Just disciplined.
Intelligence doesn't require AI
One misconception today is that "smart" software needs large language models.
It doesn't.
Once hundreds of notes share the same structure, software starts recognizing patterns.
If every contact has:
company
status
owner
email
...then a new contact probably should too.
If every project links to an account...
...missing that relationship becomes obvious.
If opportunities usually become projects...
...the software can suggest what probably comes next.
That's not AI. That's good, old fashioned, statistics.
Queries become your reports
Traditional CRM:
"Can someone build me a report?"
Markdown CRM:
Show active customers
without meetings
during the last 90 days.
The report doesn't need to exist beforehand. It's generated.
Tomorrow you ask a different question. Tomorrow you get a different report.
The underlying notes never changed.
Your CRM starts behaving like Git
This is one of my favorite parts.
Every change is text.
Git shows exactly what changed.
-status: prospect
+status: customer
Or...
-company: [[acme]]
+company: [[globex]]
No opaque database updates. No audit log locked behind an Enterprise subscription. Just version control.
The biggest surprise
The biggest surprise isn't that this works.
It's that it scales better than people think.
Not because Markdown is magical.
Because structured knowledge scales surprisingly well.
When every entity has:
- a stable identity
- consistent fields
- explicit relationships
- queryable metadata
...you've recreated most of what makes a CRM valuable.
Without needing SQL.
Without needing PostgreSQL.
Without needing Docker.
Without needing a browser.
Now, is this for everyone?
Absolutely not.
If your sales team needs Salesforce automation, marketing campaigns, AI lead scoring, an ecosystem of integrations, and enterprise workflows, buy Salesforce (I know, I know), or Pipedrive. Or about 20 other great platforms out there.
But if you're someone that likes owning their data, or establishing your own structure and have the data cater to your tendencies, then Markdown becomes surprisingly compelling.
Especially when software understands the structure hiding inside those files.
The real shift
The interesting question isn't whether Markdown can replace a CRM.
It's whether we should still think of Markdown as documentation at all.
Because once notes become structured entities, documents become databases.
Relationships become graphs. Queries become reports.
And suddenly, your knowledge base starts behaving less like a notebook and more like an operating system.
I'd argue that's a far more interesting future than yet another cloud CRM.
Maybe the next CRM isn't another SaaS product.
Maybe it's just a folder.
That's exactly why I built Yamlink. Because my contacts deserve better.
