Can I have my entire CRM setup in Markdown?

Javier Ramírez — Mon, 29 Jun 2026 01:04:24 +0000

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.

Turning Markdown Files into a Queryable Knowledge Graph

Javier Ramírez — Fri, 13 Mar 2026 15:57:51 +0000

Markdown files often contain more structure than we give them credit for.

With YAML frontmatter and consistent links, a collection of Markdown files can behave like a small knowledge graph.

Many people already use YAML frontmatter to store metadata:

---
id: mission-klendathu
type: mission
commander: [[johnny-rico]]
date: 2297-08-01
---

Once files have consistent IDs and links between them, something interesting happens:

files become nodes
[[links]] become relations
the collection of files becomes a graph

Querying Markdown

One approach is to define queries directly inside Markdown files.

If you can query that graph, Markdown stops being just documents — it becomes structured data.

For example:

!view mission where commander = [[johnny-rico]]
select date, outcome
sort date desc

The query runs over all Markdown files and returns matching nodes.

In my case, I tried building a VS Code extension to explore this idea.

Live Query Results

!view queries render results as tables inside the editor.

You can edit values directly in the table, and the changes write back to the YAML frontmatter of the source file.

Why Markdown?

Yamlink

The goal is to keep everything:

local-first
Git-native
plain Markdown

No database, no lock-in — just structured files.

Yamlink

To explore this idea, I built a VS Code extension called Yamlink.

If you're curious:

GitHub: https://github.com/javierigaciorm/yamlink

VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=yamlink.yamlink

I'm especially interested in hearing how others are working with structured data in Markdown.

DEV Community: Javier Ramírez

Can I have my entire CRM setup in Markdown?

Can You Build a CRM Entirely in Markdown?

Markdown isn't the limitation.

Relationships become links

Your filesystem becomes the database

"But where are the tables?"

A CRM is mostly relationships

Frontmatter is your schema

Intelligence doesn't require AI

Queries become your reports

Your CRM starts behaving like Git

The biggest surprise

Now, is this for everyone?

The real shift

Turning Markdown Files into a Queryable Knowledge Graph

Querying Markdown

Live Query Results

Why Markdown?

Yamlink