DEV Community: Javier Ramírez

I Ditched My Fitness App for a Folder of Markdown Files (Spoiler -It's Better)

Javier Ramírez — Tue, 11 Aug 2026 00:40:40 +0000

Let me tell you about the exact moment I knew I was over fitness apps: I opened one to log my workout, and it asked me to rate my mood in an emoji scale before it would let me type in the proper amount of lbs being worked. I didn't like it. Not. One. Bit.
I'm fickle.
Sue me. This happens as you age.
I just wanted to write down a number.

So I did what any reasonable human being does when a piece of software annoys them: I deleted it and rebuilt my entire training log in a text editor. Specifically, in Yamlink — a VS Code extension that turns plain Markdown notes into a live knowledge graph. Fitness was not quite the motivation behind its development built for notes and knowledge work. But, in about an hour, with just this plugin and zero mood-tracking emojis, I was pretty satisfied with what was done.

Here's how, and why I think it's genuinely good — not "good for a hack," just plain good.

Step 1: A workout is just a note with opinions

Yamlink's whole model rests on one idea: every note gets an id: and a type: in its YAML frontmatter, and that's basically it. No schema to define up front, no "create a Workout object" ceremony. You just... write the file. One tiny set of properties can turn your vault in an operational knowledge vault. And you can take it in any direction you want.

---
id: workout-2026-08-03
type: workout
date: 2026-08-03
exercise: back squat
sets: 5
reps: 5
weight: 185
program: "[[program-strength-block-2]]"
---

Felt heavy today. Left knee a little cranky on set 4.

That's it. That's the whole process. No ads, app login, no waiting 25 seconds before being able to log your work. It's a text file sitting in a folder I own, that'll still open in the Cyberdyne computers we'll own in twenty years, because it's Markdown, not a proprietary blob in someone else's database/platform.

Step 2: your log becomes a live, editable table, not a static list

Here's where it stops being "just notes" and starts being genuinely useful. Drop a !view block into a note and it renders as a real, interactive table pulling live data from every workout note in the vault:

!view workout sort date desc

That's not a static export. It's a live query. Change a value in the table, it writes straight back into the actual .md file. No "sync," because there's nothing to sync — the table and the file are the same data, just two ways of looking at it.

Want to see if your work is yielding results, or if you're just telling yourself a nice story?

!view workout where exercise = "back squat" sort date desc

Run it, then flip the same result set to a scatter plot from the View Panel's own toolbar — no extra syntax, just a layout toggle sitting right there. Real chart, real data, zero "connect your Watch to unlock trends" poophousery.

Step 3: link your workout to your program, because context matters

This is the part that made me actually feel something. Yamlink treats [[wikilinks]] as first-class graph edges — write [[program-strength-block-2]] anywhere and it's a real, navigable connection, not a string that happens to look like a link.

So my workout notes link to the program note they belong to, my program note links to a goal note, and suddenly I've got an actual knowledge graph of my training instead of a spreadsheet pretending to have structure. Open the graph view and you can see the shape of a training block — which workouts belong to which phase, at a glance, rendered as an actual graph, not a filtered list dressed up with a fancier font.

Step 4: let the graph do the counting for you

Yamlink has a small set of computed fields the engine tracks automatically, no formula required — _inbound_count being the one I didn't know I needed. It's just "how many other notes link to this one." Point it at my program-strength-block-2 note, and it's quietly counting every single workout I've logged against that block.

I never tally sessions. I never have. The graph already knows, because it's just counting real edges — the same links I wrote anyway to give my workouts context in Step 3, now doing double duty as a running total I didn't have to ask for.

Not math. Not AI. Just an honest count of the connections that already exist.

Step 5: the calendar knows when you skipped leg day

Every note with a date: field just... show up on Yamlink's built-in calendar, automatically. No separate "log this workout in the calendar too" step, because there's only one copy of the data, and everything reads from it.

And here's the detail I'm really loving: Yamlink has a Vault Health feature that flags notes nobody's touched in a while. It doesn't do this with a cutesy notification like "Hey champ, ready to go get the day?! 💪" — it just quietly, honestly surfaces "this hasn't been updated in 9 days" as a structural fact about your vault. No guilt-tripping of any kind. No streak-shaming push notification at 8pm on a Sunday when you felt like having a treat. Just cold, accurate silence when you're on track, and an honest flag when you're not. Somehow, I found that more motivating than the app ever was.

Step 6: it's honest about what it isn't

I want to be extremely real, because the rest of this article has been fun and kinda smug in my honest opinion: this is not a mobile app. There is no fancy iPhone experience here. Yamlink lives in VS Code (and a genuinely nice terminal UI called Conduit, if you're the type who'd rather log a set from a terminal than unlock your phone — and if you're reading a dev magazine, you know exactly who you are). If your ideal fitness tracker experience is thumb-typing while your quads are trembling mid-set, this isn't that, at least not yet.

What it is: a fitness tracker that's actually a side effect of a much more general tool — one that treats "workout" as just one possible shape a note can take, alongside "book I'm reading," "person I met at a conference," or "recipe I keep ruining." The frontmatter doesn't care what domain you point it at. It just wants a type: and some fields.

The actual pitch

Every fitness app I've used eventually turns into a subscription, a walled garden, or both. And honestly, I can live with that. Your training history — actual, real information about your actual, real body — ends up owned by a company whose business model depends on you not leaving. I can live with that too. But then, as Yamlink kept evolving, I figured I could flip the app experience to a folder of files on your own disk. You can grep it. You can git log it. You can open it in Notepad in the year 2040 and it'll still just say what it says.

Yamlink was not built to be a fitness tracker (at all). That's kind of the point — a tool that adapts to what you structure, instead of a tool that structures you into whatever the product team decided this quarter, is a genuinely different kind of software. Turns out "flexible knowledge graph" and "training log" are the same shape wearing a different type: field.

Also, no emojis. I cannot stress enough how much that matters to me at my advanced age.

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.