I Built the Same Architecture Three Times. So I'm Open-Sourcing It.

I had a realization while comparing three products I built: TechBearing, JobArchivist, and Bricktelligence.

They are not the same product wearing different skins.

TechBearing is a private, self-hosted operator platform for systems, workstreams, evidence, and automation. JobArchivist is a personal reverse ATS. Bricktelligence is a consumer product for managing a LEGO backlog.

Different domains. Different audiences. Different deployment models.

But underneath those differences, I had built the same architectural fingerprint three times.

An entity. An append-only event timeline. A lifecycle state machine. An ingestion funnel. A RAG-grounded AI persona. All sitting on a familiar Next.js and Supabase spine until the product earns the need to graduate beyond it.

I was not copying code between projects. I was re-deriving the same system from experience.

That is useful evidence—but it is also wasted motion. So I extracted the pattern and open-sourced the template as The Archivist Stack.

Three Products, One Architecture

The nouns change. The shape keeps returning.

Each product starts with something a user cares about, records what happens to it over time, moves it through a meaningful lifecycle, pulls in evidence from outside systems, and gives an AI agent grounded access to that history.

That is the architecture.

The Part Worth Reusing

The reusable part is not the product. It is the machinery every product needs before its domain becomes interesting:

1. Supabase authentication, row-level security, and numbered migrations.
2. An entity with a one-to-many event timeline.
3. Explicit lifecycle states with guarded transitions.
4. Documents, extracted text, chunks, embeddings, and retrieval.
5. Conversations, messages, tools, and a grounded agent loop.
6. A source-to-normalize-to-upsert ingestion interface.
7. A persona with durable facts and memory extraction.
8. Tests, CI, and deployment scaffolding.

Rename the entity. Replace the lifecycle values. Plug in a new ingestion adapter. Give the agent a different purpose.

The plumbing remains useful.

The Part That Must Stay Product-Specific

A template becomes dangerous when it mistakes shared infrastructure for shared product design.

TechBearing still needs system inventory, workstream state, service health, runbook automation, operational integrations, and agent tool surfaces.

JobArchivist still needs role discovery, compensation research, resume and cover-letter workflows, and the emotional reality of a job search.

Bricktelligence still needs barcode and vision recognition, set catalogs, bag tracking, end-of-life monitoring, billing, a creator network, and a mobile experience that works beside a pile of bricks.

Those differences are the products. I do not want a framework that abstracts them away. I want one that gets out of their way sooner.

The Archivist Stack

It is called The Archivist Stack, and the repository is public now.

Two of the products already use the Archivist idea directly. More importantly, the name captures what the architecture does: it turns a changing domain into structured history that both people and agents can understand.

The open-source template is designed around:

• Next.js, Supabase, row-level security, and a numbered-migration harness.
• An entity, event timeline, and lifecycle-state pattern.
• A complete RAG path from document ingestion to grounded retrieval.
• An AI persona kit with tools, durable facts, and memory extraction.
• A pluggable ingestion pipeline.
• Vitest, Playwright, CI, and sensible deployment defaults.

Billing, multi-tenancy, mobile, and domain integrations will remain optional. A new product should not inherit complexity it has not earned.

The Part Even the Open Repo Keeps

Here is the part that surprised me: the line between commodity and moat runs inside the shared machine, not just around it.

The scoring engine is open. The weights it uses are not.

The memory extractor is open. The confidence floor that decides what is worth remembering is not.

The persona framework is open. Its voice—the prompt that makes it sound like my product instead of a generic assistant—is not.

None of the mechanism is novel. That is the point. Weighted scoring, threshold buckets, embedding search, and fact extraction are all standard techniques. None of them is defensible, and none of them is worth hiding.

The tuning is different.

It is not patentable. It is simply earned: the result of watching real users and adjusting the system until it feels right. So the calibration lives in one file, calibration.ts, and that file is git-ignored.

Open the engine. Keep the numbers.

TechBearing Is the Operator-Scale Reference

TechBearing matters to this story because it is an educational reference for where the pattern can go. It runs privately in my homelab; it is not a publicly available service or customer deployment.

Its reference architecture explores the graduation beyond a monolith: roughly 15 Go services, an API gateway, independent data ownership, Kubernetes, Helm, Argo CD, Redis, and an MCP layer that exposes live operational context to agents.

That is not where a new product should begin.

It is evidence that the simpler architecture has an escape hatch. Start with one coherent system. Find product-market evidence. Split boundaries only when operations, scaling, or team ownership makes the cost worthwhile.

The template encodes a starting point, not a prescribed ending.

Why Open-Source It

The selfish reason is speed. Product number four should begin with its domain, not another weekend rebuilding authentication, migrations, an event log, and a retrieval loop.

The professional reason is more interesting: a public template makes the architecture inspectable.

Anyone can claim a repeatable approach. A maintained repository—with migrations, security policies, tests, decisions, and working examples—lets other engineers evaluate the approach for themselves.

It also creates a better feedback loop. The first three implementations were shaped by three products. The next version can be shaped by other builders finding the edges I have not encountered yet.

It is The Archivist Stack, released under Apache-2.0 with the patent grant included. Build a business on it if you want. I would rather it get used than admired.

If this looks unremarkable, good. Every piece of it is standard: an entity table, an event log, vector search, a state machine. A moat built from standard parts is not a moat—which is exactly why I can open it without giving anything away.

Explore or fork The Archivist Stack on GitHub →

The Realization

I thought I had three separate codebases that happened to rhyme.

What I actually had was one architectural instinct, tested at three levels of maturity:

• JobArchivist is the compact version.
• Bricktelligence is the commercial version.
• TechBearing is the operator-scale reference version.

Extracting the shared spine does not make those products less distinct. It makes the distinction clearer. The template handles the recurring machinery. The product earns its identity in everything layered on top.

I built the pattern three times before I could see it.

The fourth time, I want to start from it.