How I Built Graphify: Turning Any Input Into a Knowledge Graph

TL;DR

Graphify is my personal context orchestration engine. Feed it anything—questions, files, URLs, logs, screenshots—and it transforms the input into an indexed knowledge graph. When I query Claude with a prompt, Graphify returns the 5-10 most relevant nodes in < 50 ms. Result: AI answers become coherent, sourced, and grounded in my actual decisions. That's the difference between a hallucinating LLM and a reasoning assistant.

1. Why Graphify Exists

Before Graphify, my workflow looked like this:

Hit a hard question on a project.
Hunt for context across 15 scattered places (Obsidian notes, git repos, archived Slacks).
Copy-paste fragments into Claude's context window.
Get a response: often good, sometimes off because I missed a crucial detail.

The problem: fragmented context kills response quality.

With 44 real projects (plus dormant ones), it gets worse fast. LLMs don't hallucinate out of malice—they invent when information is missing. Even with solid prompts, without the exact context, you lose 40-60 % accuracy.

I tried the classics:

Obsidian + plugins: good for note-taking, weak for real-time retrieval.
Naive RAG (simple vector embeddings): forgets metadata, returns semantically close but irrelevant stuff.
Notion + full-text search: slow and fragile on nuanced queries.

None solved the real problem: how do you structure knowledge so it finds itself when you need it?

2. The Insight: Think in Graphs, Not Documents

A directed graph is simple: nodes (entities—projects, decisions, skills, bugs) and edges (relations—"depends on," "contrasts with," "could apply to").

Example: dims_portfolio is a node. Its dependencies (Next.js, Prisma, Tailwind) are nodes. Published articles (Flutter vs RN, GigaBracket) are nodes. Architectural decisions (dual-graph MCP, version-bump before commit) are nodes. The graph encodes semantic links, not just keywords.

Query: "What's my versioning policy?"

Graphify:

Interprets the query (search for nodes tagged "version").
Walks the graph (follows edges).
Returns all directly connected or two-hop-away nodes.
Ranks by relevance (graph distance, recency, prompt score).
Returns results to Claude's context.

More robust than vector indices: connections are explicit.

3. Architecture & Engine

Graphify runs in two modes: local (MCP on my machine) and server (for teams or scale).

Local mode (MCP)

Data in SQLite (.claude/graphify/db.sqlite).
MCP process exposing three endpoints: graph_continue, graph_scan, graph_add_memory.
Latency: < 10 ms read, < 50 ms index a new node.
No network, no third parties: everything stays private.

Server mode

PostgreSQL + Supabase RLS (per-user isolation).
REST API, webhooks for sync.
Realtime via WebSocket (watch teammates add to the graph).

I run local for my portfolio (DIS, Giga, Perso). Experimenting with server mode for SaaS clients.

Indexing

Semi-automatic:

Manual scans: graph_scan /path/to/project reads files, extracts symbols (functions, types, DB tables), creates nodes.
Active edits: when I log a decision, bug, or product milestone, I call graph_add_memory with a one-liner + tags + related files.
Webhooks: repos send POST to Graphify on commit. Commit title becomes a node, linked to changed files.

Result: the graph updates passively. Zero friction to maintain.

4. Real Results

Before Graphify

Query: "In dims_portfolio, what's the OG image slug for the Flutter vs React Native 2026 article?"

Time to find: 2-3 min (40+ mdx files, confused structure).
Claude's answer (blind): "Probably flutter-vs-react-native.png."
Reality: flutter-vs-react-native-2026.png and -en.png (I'd forgotten the -en).

After Graphify

Same query.

Time to retrieve: < 100 ms (Graphify returns the mdx + linked assets + EN versions).
Claude: "flutter-vs-react-native-2026.png and flutter-vs-react-native-2026-en.png. The EN OG is -en.png."
Accuracy: 100 %.

Measured Impact

| Metric | Before | After | Gain | |--------|--------|-------|------| | Context retrieval time | 2-5 min | < 100 ms | 20-50× faster | | AI hallucinations (missing context) | ~40 % | < 5 % | 8× fewer | | Confidence in AI answers | ~60 % | ~95 % | +35 pp | | Time to onboard a new decision | 5-10 min | 30 sec | 10-20× faster |

The main win isn't speed (though 100 ms is good). It's coherence: the AI always has the right facts.

5. Real Use Cases

Case 1: Cascading Architecture Decision

I want to change versioning strategy in dims_portfolio. Query: "If I move from version-bump pre-commit to post-merge, what breaks?"

Graphify returns:

Current decision (version-bump in CLAUDE.md).
Last 3 commits touching version-bump.
The version-bump script itself.
5 articles mentioning the strategy.
All affected PRs.

Claude lists every impact. Without Graphify, I'd miss 2-3 dependencies.

Case 2: Onboarding a New Dev

Teammate: "I'm starting on GigaBracket. How's this built?"

Instead of a 1-hour call, I run graph_scan /path/to/gigabracket. Graphify returns:

Architecture (app/ → pages, components/, lib/ → formats/, pocketbase/).
Key decisions (why PocketBase, why Next.js 16).
Full stack (Next.js, Tailwind, Radix, next-intl, etc.).
Last 3 articles/decisions on this project.

Claude generates a 2-page summary. New dev understands 80 % in 10 min.

Case 3: Performance Regression Analysis

A portfolio mdx loads slowly. Query: "Why is portfolio.ts slow in production?"

Graphify returns:

The portfolio.ts file.
Importing components (ProductCard, etc.).
Decisions around this file (why it's structured this way).
Associated Lighthouse metrics.
PRs that touched it.

Claude analyzes the dependency layers. Without Graphify, it's guessing.

6. Pitfalls & Limits

Data Quality Problem

Garbage in, garbage out. If nodes are poorly labeled or the graph disorganized, results are wrong. I spent time standardizing:

Node names (no duplicates, clear conventions).
Tags (controlled vocabulary, not 20 variants of "bug").
Descriptions (one sentence, < 15 words).

Fix: audit the graph monthly. 30 minutes to check for orphaned or miscategorized nodes.

Graph Scalability

I'm at ~5k nodes across 44 projects (50-100 per project). Still very manageable. But past 10k+, performance degrades without optimization (spatial indexing, clustering).

Strategy: at 8k nodes, split by tenant (DIS-graph, Giga-graph, Perso-graph). Each runs independently. Cross-tenant queries go through a fusion layer.

False Connection Noise

More nodes = more risk of accidental edges. Example: "bug" and "blocker" feel related (both = obstacles) but semantically they're different.

Fix: manual validation before committing critical edges, and a confidence score per edge (0.7 = probable, 0.95 = confirmed).

7. How I Built It

Stack

Backend: Node.js 22 + Fastify (server mode) or pure MCP (local mode).
DB: SQLite (local) or PostgreSQL (server).
Graph engine: custom (not Apache Jena or Neo4j—too heavy for my needs).
LLM: Claude API for query interpretation (I use Claude to understand the question before hitting the graph).

Yes, it's recursive: I use Claude to ask Claude to answer. But it works because the first query is cheap (just parse), then Graphify returns context, then the second query is precise.

Iterative Development

Not built in a week. Simple SQLite + bash scripts (October 2024). Then an MCP client (December 2024). Then the API layer (February 2025). Webhooks for git (April 2025). Performance tuning (July 2026).

Each iteration fixed a specific problem. No feature creep.

8. Lessons for You

If you build something similar:

1. Start small. SQLite + 5 test nodes. Add complexity when you feel it.

2. Standardize early. Node names, tags, formats. One week up front saves hours later.

3. Test retrieval. Write 10 real questions you'd actually ask. Can Graphify answer them? If not, adjust the graph.

4. Expose a simple API. Even if it's just for you. Makes it possible to add tooling later (webhooks, CLI, UI).

5. Measure and optimize. Graphify must hit < 100 ms p99 latency to feel useful. 500 ms, nobody waits.

6. Plan for refactoring. In 8 months, my graph structure changed 3 times (JSON → SQLite → multi-tenant). Normal. Keep migrations reversible.

9. What's Next

Graphify is stable for solo use. Current experiments:

Multi-tenant SaaS: hosted version for agencies. Beta September 2026.
Graph visualization: web UI to explore the graph. Currently text-only.
Auto-extraction: use Claude to extract entities from articles/notes and auto-create nodes. Risky (hallucinations) but interesting.
Time-travel: see the graph at a past date. Useful for debugging or analyzing how decisions evolved.

Conclusion

Graphify isn't revolutionary. It's a straightforward answer to a real problem: how do you keep context coherent across 44 projects and a finite brain?

The real win isn't the tech. It's shifting how I use LLMs: from text generators to reasoning partners. With the right context, Claude almost never hallucinates. With wrong or missing context, even GPT-4 derails.

If you have scattered projects, decisions, docs: you don't need Graphify. Just need a DB + a few scripts. The idea matters more than the tool.

Graphify has been in production on all my projects since April 2025. Code is private for now—opening to the public in 2027 when it's more mature.

TL;DR

1. Why Graphify Exists

Before Graphify, my workflow looked like this:

Hit a hard question on a project.
Hunt for context across 15 scattered places (Obsidian notes, git repos, archived Slacks).
Copy-paste fragments into Claude's context window.
Get a response: often good, sometimes off because I missed a crucial detail.

The problem: fragmented context kills response quality.

I tried the classics:

Obsidian + plugins: good for note-taking, weak for real-time retrieval.
Naive RAG (simple vector embeddings): forgets metadata, returns semantically close but irrelevant stuff.
Notion + full-text search: slow and fragile on nuanced queries.

None solved the real problem: how do you structure knowledge so it finds itself when you need it?

2. The Insight: Think in Graphs, Not Documents

A directed graph is simple: nodes (entities—projects, decisions, skills, bugs) and edges (relations—"depends on," "contrasts with," "could apply to").

Query: "What's my versioning policy?"

Graphify:

Interprets the query (search for nodes tagged "version").
Walks the graph (follows edges).
Returns all directly connected or two-hop-away nodes.
Ranks by relevance (graph distance, recency, prompt score).
Returns results to Claude's context.

More robust than vector indices: connections are explicit.

3. Architecture & Engine

Graphify runs in two modes: local (MCP on my machine) and server (for teams or scale).

Local mode (MCP)

Data in SQLite (.claude/graphify/db.sqlite).
MCP process exposing three endpoints: graph_continue, graph_scan, graph_add_memory.
Latency: < 10 ms read, < 50 ms index a new node.
No network, no third parties: everything stays private.

Server mode

PostgreSQL + Supabase RLS (per-user isolation).
REST API, webhooks for sync.
Realtime via WebSocket (watch teammates add to the graph).

I run local for my portfolio (DIS, Giga, Perso). Experimenting with server mode for SaaS clients.

Indexing

Semi-automatic:

Manual scans: graph_scan /path/to/project reads files, extracts symbols (functions, types, DB tables), creates nodes.
Active edits: when I log a decision, bug, or product milestone, I call graph_add_memory with a one-liner + tags + related files.
Webhooks: repos send POST to Graphify on commit. Commit title becomes a node, linked to changed files.

Result: the graph updates passively. Zero friction to maintain.

4. Real Results

Before Graphify

Query: "In dims_portfolio, what's the OG image slug for the Flutter vs React Native 2026 article?"

Time to find: 2-3 min (40+ mdx files, confused structure).
Claude's answer (blind): "Probably flutter-vs-react-native.png."
Reality: flutter-vs-react-native-2026.png and -en.png (I'd forgotten the -en).

After Graphify

Same query.

Time to retrieve: < 100 ms (Graphify returns the mdx + linked assets + EN versions).
Claude: "flutter-vs-react-native-2026.png and flutter-vs-react-native-2026-en.png. The EN OG is -en.png."
Accuracy: 100 %.

Measured Impact

The main win isn't speed (though 100 ms is good). It's coherence: the AI always has the right facts.

5. Real Use Cases

Case 1: Cascading Architecture Decision

I want to change versioning strategy in dims_portfolio. Query: "If I move from version-bump pre-commit to post-merge, what breaks?"

Graphify returns:

Current decision (version-bump in CLAUDE.md).
Last 3 commits touching version-bump.
The version-bump script itself.
5 articles mentioning the strategy.
All affected PRs.

Claude lists every impact. Without Graphify, I'd miss 2-3 dependencies.

Case 2: Onboarding a New Dev

Teammate: "I'm starting on GigaBracket. How's this built?"

Instead of a 1-hour call, I run graph_scan /path/to/gigabracket. Graphify returns:

Architecture (app/ → pages, components/, lib/ → formats/, pocketbase/).
Key decisions (why PocketBase, why Next.js 16).
Full stack (Next.js, Tailwind, Radix, next-intl, etc.).
Last 3 articles/decisions on this project.

Claude generates a 2-page summary. New dev understands 80 % in 10 min.

Case 3: Performance Regression Analysis

A portfolio mdx loads slowly. Query: "Why is portfolio.ts slow in production?"

Graphify returns:

The portfolio.ts file.
Importing components (ProductCard, etc.).
Decisions around this file (why it's structured this way).
Associated Lighthouse metrics.
PRs that touched it.

Claude analyzes the dependency layers. Without Graphify, it's guessing.

6. Pitfalls & Limits

Data Quality Problem

Garbage in, garbage out. If nodes are poorly labeled or the graph disorganized, results are wrong. I spent time standardizing:

Node names (no duplicates, clear conventions).
Tags (controlled vocabulary, not 20 variants of "bug").
Descriptions (one sentence, < 15 words).

Fix: audit the graph monthly. 30 minutes to check for orphaned or miscategorized nodes.

Graph Scalability

I'm at ~5k nodes across 44 projects (50-100 per project). Still very manageable. But past 10k+, performance degrades without optimization (spatial indexing, clustering).

Strategy: at 8k nodes, split by tenant (DIS-graph, Giga-graph, Perso-graph). Each runs independently. Cross-tenant queries go through a fusion layer.

False Connection Noise

More nodes = more risk of accidental edges. Example: "bug" and "blocker" feel related (both = obstacles) but semantically they're different.

Fix: manual validation before committing critical edges, and a confidence score per edge (0.7 = probable, 0.95 = confirmed).

7. How I Built It

Stack

Backend: Node.js 22 + Fastify (server mode) or pure MCP (local mode).
DB: SQLite (local) or PostgreSQL (server).
Graph engine: custom (not Apache Jena or Neo4j—too heavy for my needs).
LLM: Claude API for query interpretation (I use Claude to understand the question before hitting the graph).

Yes, it's recursive: I use Claude to ask Claude to answer. But it works because the first query is cheap (just parse), then Graphify returns context, then the second query is precise.

Iterative Development

Each iteration fixed a specific problem. No feature creep.

8. Lessons for You

If you build something similar:

1. Start small. SQLite + 5 test nodes. Add complexity when you feel it.

2. Standardize early. Node names, tags, formats. One week up front saves hours later.

3. Test retrieval. Write 10 real questions you'd actually ask. Can Graphify answer them? If not, adjust the graph.

4. Expose a simple API. Even if it's just for you. Makes it possible to add tooling later (webhooks, CLI, UI).

5. Measure and optimize. Graphify must hit < 100 ms p99 latency to feel useful. 500 ms, nobody waits.

6. Plan for refactoring. In 8 months, my graph structure changed 3 times (JSON → SQLite → multi-tenant). Normal. Keep migrations reversible.

9. What's Next

Graphify is stable for solo use. Current experiments:

Multi-tenant SaaS: hosted version for agencies. Beta September 2026.
Graph visualization: web UI to explore the graph. Currently text-only.
Auto-extraction: use Claude to extract entities from articles/notes and auto-create nodes. Risky (hallucinations) but interesting.
Time-travel: see the graph at a past date. Useful for debugging or analyzing how decisions evolved.

Conclusion

Graphify isn't revolutionary. It's a straightforward answer to a real problem: how do you keep context coherent across 44 projects and a finite brain?

If you have scattered projects, decisions, docs: you don't need Graphify. Just need a DB + a few scripts. The idea matters more than the tool.

Graphify has been in production on all my projects since April 2025. Code is private for now—opening to the public in 2027 when it's more mature.

TL;DR

1. Why Graphify Exists

2. The Insight: Think in Graphs, Not Documents

3. Architecture & Engine

Local mode (MCP)

Server mode

Indexing

4. Real Results

Before Graphify

After Graphify

Measured Impact

5. Real Use Cases

Case 1: Cascading Architecture Decision

Case 2: Onboarding a New Dev

Case 3: Performance Regression Analysis

6. Pitfalls & Limits

Data Quality Problem

Graph Scalability

False Connection Noise

7. How I Built It

Stack

Iterative Development

8. Lessons for You

9. What's Next

Conclusion

Get the Graphify guide

La newsletter qui ne perd pas ton temps.

Une lettre par mois, sur ce que je construis et ce que j’apprends.

TL;DR

1. Why Graphify Exists

2. The Insight: Think in Graphs, Not Documents

3. Architecture & Engine

Local mode (MCP)

Server mode

Indexing

4. Real Results

Before Graphify

After Graphify

Measured Impact

5. Real Use Cases

Case 1: Cascading Architecture Decision

Case 2: Onboarding a New Dev

Case 3: Performance Regression Analysis

6. Pitfalls & Limits

Data Quality Problem

Graph Scalability

False Connection Noise

7. How I Built It

Stack

Iterative Development

8. Lessons for You

9. What's Next

Conclusion

Get the Graphify guide

La newsletter qui ne perd pas ton temps.