Siegfried - Development Control Plane
The base I built to research, document and ship a series of five small products: a markdown vault that works as long-term memory, semantic search over it, and a kanban that tracks every satellite project from idea to launch.
Role
Design & Development
Stack
Next.js, Supabase, pgvector
Scope
1 hub + 5 satellites
Timeline
18 days
1. Overview
Siegfried is a project about building projects. I wanted a set of focused demos, each in a domain that is not my own (developer platforms, underwater acoustics, compliance, drone planning and operations consoles), and I wanted them to come out consistent, honest and fast. So before the first one I built the place where they would be planned, written down and tracked.
It is three things in one Next.js app: a vault of markdown notes with frontmatter, a RAG search over that vault backed by Supabase and pgvector, and an operational dashboard with a card and a checklist per satellite. Each satellite then lives in its own repository, with its own mythological name and its own visual identity.
⚠️ The Problem
Building several small products in a row fails in predictable ways:
- Lessons get lost between builds, so the same Next.js and tooling traps cost time again
- Every app looks the same, or worse, looks like a recolour of the previous one
- Status lives in your head and drifts between machines
- Demos overclaim: a simulated feed quietly presented as a real system
✓ The Solution
Write it down, make it searchable, track it live. Every decision and gotcha becomes a vault note, the vault is indexed for semantic search, and each satellite's stage and checklist sit in a shared database. A written playbook (benchmark first, then identity, then build, then an honest docs page) made each new app start from where the last one ended.
2. The Dashboard
The home page is a hero with live counts and a project grid filtered by stage. Every card shows the project's concept, its stage and the progress of its production checklist.
Each project has a detail page in the spirit of a Vercel project card: links to the repository and to the vault spec, the deploy state, a stage selector and the editable checklist. Changes are written straight to Supabase, so the local app and a deployed one always show the same state.
3. The Vault
The vault is a folder of markdown files split into research, projects, decisions and docs. Every note carries the same frontmatter (type, project, tags, status and dates), and the dashboard renders it with a sidebar that expands on hover. A private/ folder holds personal job-search research: it is gitignored and is never indexed, locally or in the cloud.
A sidebar that does not jump
The collapsed rail and the expanded panel share a fixed header zone and the same content offset, and the expanded panel overlays the page instead of pushing it. It sounds small, but every earlier version jumped on hover, and the same pattern was later reused for Janus's assistant.
4. Architecture
The files stay the source of truth, and the database only holds what has to be shared live.
Indexer: Splits each note by ## heading, embeds every chunk with Voyage (voyage-4-lite, 1024 dimensions) and replaces that note's rows. It paces itself for the free tier and retries on rate limits.
Search: An API route embeds the question and calls a match_vault_chunks SQL function, with optional project and type filters. It returns ranked chunks and no generated text: the vault is for finding my own notes, not for chatting with them.
Project state: A satellite_projects table with the stage and a five-item checklist replaced an earlier projects.json file, which would not survive an ephemeral deploy.
Access: A cookie gate in proxy.ts and the new Supabase secret-key format, used only on the server.
5. The Satellite Playbook
The most useful thing in the vault turned out to be a document of recurring patterns, updated after every build. It covers Next.js 16 with Cache Components (where Suspense is needed, which runtime flags break the build), MapLibre under Turbopack, lint rules that only eslint catches, and a habit of precomputing small corpora into static files instead of standing up a database per app.
Design: one family, five identities
The first version of Janus only swapped Siegfried's palette for a warm one, and it read as a reskin. The rule that replaced it: a shared neutral base for every surface, and a difference made of an accent reserved for functional signals, a type pairing, a corner radius and a layout grammar. Each identity started from two or three real products in that domain, studied from screenshots rather than from memory.
6. The Satellites
| Project | What it shows |
|---|---|
| Janus | A developer platform portal with a RAG assistant over its own docs. |
| Siren | An interpretation layer over a real underwater vessel-noise classifier. |
| Themis | LLM-generated NIST SP 800-171 findings on infrastructure-as-code. |
| Athena | A drone swarm mission planner with real coverage-path geometry. |
| Argus | A simulated operations console with an explainable rules engine. |
Each one has its own case study: Janus, Siren, Themis, Athena and Argus.
Argus, the last one, was built entirely by a remote cloud agent from a single self-contained brief. The remote environment could not see the vault, so the brief had to restate the whole playbook, which was a good test of how complete that playbook had become.
7. Decision Records
Hosted pgvector over a local vector store
Local and production share one live database, so there is no sync step and no drift.
Retrieval only, no generation
Siegfried returns ranked chunks and lets me open the note. Janus is where generation on top of retrieval was explored.
Sibling repositories, not a monorepo or submodules
Each satellite is independent and shares patterns, not code. The tracker table does the job submodules would have done, with none of their fragility.
Three stages and one checklist
Unlike my Conquest Brain pipeline with thirteen gated stages, the satellites are homogeneous small web apps, so ideation, production and launched, plus a five-item checklist, were enough.
8. Outcome
6
apps shipped
18
days, start to finish
~11k
lines of code
16
vault notes indexed
5
visual identities
Key Takeaways
- Write the gotcha down once: Each satellite was faster than the one before, mostly because its traps were already in the vault.
- Identity is more than a palette: Accent, type, radius and layout made five apps feel distinct while still clearly coming from the same designer.
- Honesty is a feature: Every satellite has a page that says what is real and what is simulated, and that is part of what each one demonstrates.
- Right-size the infrastructure: Only Siegfried needed a database. The satellites precompute small corpora into static files.
Next steps: One-click deploys from the project page through the Vercel API, and a check that warns when vault notes are newer than the last index.