Lesson completed!
-

Lesson 18 / 21 · Make It a System

Files as a Database

Max Techera
Next

Files as a Database

Here's the move that separates a system from a clever chat: everything lives as files. Not in a conversation window, not in your head — as JSON and markdown on your disk that Claude reads at the start of every session.

data/mine → your analyticsdata/refs → competitor intelvault → hooks + CTAsOne schema across both

The chat that forgets

When you use AI in a chat, the knowledge dies with the window. You spot a great hook on Tuesday, close the tab, and by Friday it's gone. Next week you start from zero — same questions, same context, same blank slate. The tool never gets smarter because it never remembers.

A file doesn't forget. When your competitor tracker writes each post to data/refs/<creator>/<shortcode>.json, that intel is still there next month. When your dashboard writes each of your reels to data/mine/<id>.json, your history accumulates. Every session, Claude reads what's already on disk — so the system knows more every week instead of resetting to nothing.

That's the whole reason this compounds. Not because the AI is smart. Because the data stays.

Two folders, one schema

The setup is simple on purpose:

  • data/mine/ — your own reels, the real analytics pulled via the Meta API (reach, saves, shares, watch time — owner-only).
  • data/refs/ — competitor and reference posts, organized by creator.

The part that matters: both share one schema. Same fields, same shape — views, saves, shares, watch time, outlier_multiplier. Your data and their data speak the same language.

Why does that matter so much? Because it lets the vault rank hooks across both at once. You can ask a single question — "which hooks are outliers in my niche, and which of those have I actually landed in my own content?" — and the system answers it in one pass, because everything is comparable. Two different schemas would mean reconciling them by hand every single week. One schema means the system does the cross-referencing for you.

This is the atoms / refs model from my real content-OS: every piece of content — mine or someone else's — is stored as a small, uniform record. Uniform records are what make querying, ranking, and comparing trivial.

Info:

Think of data/mine and data/refs as two tables in the same database, with identical columns. The vault is a query that runs across both. That's only possible because the schema is shared — design it that way from the start.

Why files beat a "real" database

You might wonder why not just use Postgres from day one. For a single creator's content OS, plain files win: they're diffable, versionable with git, readable by eye, and Claude can grep them directly with zero setup. You get 90% of a database's value with none of the ceremony. (When you scale scraping to thousands of posts, you add a real queue and store — we'll get to that in the automation lesson — but the files-first model is where you start and where the leverage is.)

Knowledge check

Why do data/mine and data/refs share one schema?

Key takeaway

Store everything as files, not in a chat. A chat forgets; files persist and compound — the system knows more every week. Keep data/mine (your analytics) and data/refs (competitor intel) on one shared schema so the vault can rank hooks across both at once. Uniform records are what make the whole thing queryable.

Share