Tesseract & the data stack

A data platform that runs on one Mac

I wanted to see what my own systems were actually doing, not guess. So I directed the build of a small, complete data platform on a single Mac Mini: a home server for my knowledge vault and agents, a local modern data stack that turns their activity into tested tables, and a native app, Tesseract, that shows all of it without opening a terminal.

What I did, and what I didn't

I didn't write the code. Claude Code did, working as the implementing engineer: 146 of the 188 commits in the home-server repository and 53 of the 59 in Tesseract are co-authored by it.

My part was the part that decides whether the code is worth anything: what each system is for, what it must never do, the order it got built in, describing each feature in plain language, and checking the result in the running app before accepting it. A passing build was never the finish line.

The data stack

The pipeline follows the medallion pattern, entirely on local, free tools:

• Bronze. Raw JSON lands untouched from six sources: machine snapshots, agent runs, agent deliveries, device telemetry, media encodes and job applications.
• Silver. dbt-core cleans and types each one as a view.
• Gold. dbt-core rolls them up into per-day tables for machine health, agent activity and media encodes.
• Warehouse. DuckDB. The build writes one file and publishes a copy that dashboards read, because DuckDB allows one writer or many readers, never both. An open dashboard would otherwise block every rebuild.
• Around it. Dagster for orchestration, Redis as an event bus, Metabase for dashboards.

Nine dbt models, and 26 data-quality tests that all passed on the last build. Nothing reaches Gold without going through those tests.

Making the pipeline visible

A data stack you can only operate from a terminal is a data stack one person can operate. So I specified three views in Tesseract.

GodState. A live map of everything the home Mac reports about itself — hardware, network, services, agents, knowledge, skills, models and software — with what needs attention pulled to one list. Every fact comes from the machine directly; no model is asked to guess.

MDS. The pipeline drawn live from the machine: every dataset, model and service, the lineage between them, and whether each is healthy. I asked for it to be discovered rather than hard-coded, so a new dbt model appears on the next refresh. Each health finding carries a button for its own fix — "Gold is behind" comes with Build Gold — and the stack's commands (build, test, doctor, start and stop services) run from the same screen with their output streamed underneath.

View Data. A full-screen, paced presentation of the Gold tables for someone who has never opened a dashboard: one big number or chart per slide, one sentence that says what it means, and the table it came from. It builds itself from whatever tables exist, so it keeps working as the data changes.

What this is evidence of

For a data role, the useful part isn't the Swift. It's the habits:

• Keep raw data untouched, and put tested transformations between it and anything a person reads.
• Separate whatever writes the warehouse from whatever reads it.
• Make pipeline health visible, and put the fix next to the problem.
• Lead with the number, say what it means in one sentence, cite the source.
• Accept work only after using it.

I'm honest about the gap, too: I read SQL and dbt well enough to follow what a model does, but I don't write them yet. That's what I'm building now.

Honest status

In use on my own machines. The home-server app has had 54 versioned releases since September 1 and Tesseract 10 since September 7. They're code-signed with a development certificate but not notarized, so they install by hand, and no one else runs them.