Digital Braid is a company of one. I build AI workflow automation for businesses that live in Word, Excel, and PDF — construction, real estate, professional services. The work is discovery calls, feasibility scoring, iterative builds, branded deliverables, handoffs, renewals. Which means that even at a headcount of one, I have everything a go-to-market team has: a pipeline of prospects at different stages, active engagements with due dates, emails waiting on replies from both directions, and a library of reusable code that is the actual compounding asset.
The default answer to this shape of problem is to buy it: a CRM for the pipeline, a project tracker for the engagements, maybe a dashboard product on top. I have run that stack before. The tools are fine. What kills you is the sync tax — every one of them is a second copy of reality that you maintain by hand, and the moment you get busy (which is the moment you need them), they start lying to you.
So I built the other thing.
The files are the CRM
Every client is a folder. Every prospect is a folder. Inside each one there are three files a human can edit in ten seconds:
status.yaml— who they are, what stage things are at, what the next action is and when it's duerunbook.md— everything I've learned about their business, accumulated over the engagementtasks.md— a plain markdown checklist
That's the whole data model. Moving a prospect from "discovery done" to "proposal sent" is a one-line edit in a text editor, not a form with eleven required fields. The files live in git, so the pipeline has version history. And there is no second copy of reality anywhere, so nothing can drift.
The obvious objection is that a folder of YAML files isn't a system, it's a filing habit. That's correct, and it's why the dashboard exists.
Mission control that writes nothing
A small local server — FastAPI, a filesystem watcher, thirteen parsers — reads the folders and renders mission control in a browser tab. Eight tabs: an action queue for today, per-engagement status cards, the pipeline as a Kanban board, the reusable-code library cross-referenced with which clients import each module, session analytics, transcript search, an inventory of installed AI tooling, and environment health.
The dashboard has one inviolable property: it only ever reads. It writes nothing. If it died tomorrow, nothing would be lost, because the files are the system and the dashboard is just a lens. That single constraint removed an entire category of design problems — no edit conflicts, no permissions, no "which copy is right." The YAML is right, always, because it's the only copy.
The part that makes it feel like magic is the session telemetry. I do most of my building inside Claude Code, which writes every session transcript to disk as JSONL as a side effect of me working. The dashboard tails those files. It knows a session is live within seconds of me typing in a terminal. It counts tokens per model and computes what each engagement actually cost. And it attributes every session to a client automatically, by watching which file paths the tools touch — work on clients/meridian/… and that session, its cost, and its recent activity all roll up to Meridian without anyone logging anything.
That's the trick I'd point at if someone asked what "AI-native operations" means concretely. Not a chatbot bolted onto a CRM. Telemetry that already exists because of how you work, parsed into answers to the questions an operator actually asks: what's live, what's overdue, who's waiting on me, what did this engagement cost.
AI proposes, with receipts
There's one place where a model is allowed to interpret rather than count: the runbook scan. Each engagement card has a button that sends that client's runbook to Claude and gets back a two-sentence "where we are," a list of action items, and open questions.
Two rules keep it honest. Every extracted action item carries the runbook line number it came from and a confidence level, so I can always check the receipt. And results are cached by content hash, so re-scanning an unchanged runbook costs nothing.
That's the same posture I take in client work: deterministic code for anything where a wrong number is unacceptable, and when a model does interpret, it shows its sources. The dashboard runs on the rules I sell.
Publishing it without leaking anything
I wanted a public, clickable version — a dashboard whose entire job is surfacing client data, published on the open internet. That's the last thing you casually ship, and making it safe turned out to be the most interesting engineering in the project.
The demo pipeline builds a synthetic workspace from scratch: three invented clients and eight invented prospects on the reserved .example TLD, fabricated Claude-session transcripts with plausible token usage, canned LLM-scan results. Then it runs the real, unmodified server against that fake world and snapshots the API responses into static JSON. What you click in the demo is the actual product reading actual files — the files just happen to be fiction.
The last step of the build is a blocklist gate: it greps the entire output bundle for real client names, people, and domains, and hard-fails the build — deleting the bundle — on any hit.
That gate earned its keep on day one. In one test configuration, the server module had already been loaded in-process pointing at my real workspace before the demo pipeline set its overrides, so the snapshot quietly captured real engagement data. The gate caught it and killed the build. The fix was one line. The lesson is the reason the gate exists: never trust a sanitization step you haven't watched fail.
The demo is live on the builds page — click through the pipeline, open a client card, run a scan.
Why I'm writing this up
Because I think this is what GTM engineering looks like for most of the economy, and almost nobody is building for it.
The GTM engineering conversation happens almost entirely inside tech companies: enrichment waterfalls, outbound sequencing, revenue-ops tooling for teams with a seven-figure software budget. Meanwhile the median business that could benefit from exactly this thinking is a twelve-person contractor whose pipeline lives in a spreadsheet and whose "CRM" is the owner's inbox. They will never buy the stack. But a folder of YAML, a parser, and a model with receipts? That's within reach of every one of them — it's what I deploy for clients, and it's what I run myself.
I was my own first client. The system above is the proof of concept, and every client engagement since has been a variation on its rules: files the operator owns, deterministic code for the numbers, AI that proposes instead of decides. If go-to-market is being rewritten by AI — and it is — the rewrite shouldn't stop at companies that already have a rev-ops team.