Siegfried satellite · 1 of 5
Janus - Developer Platform Portal
The kind of internal tool a platform engineering team builds for its own engineers, in miniature: a service catalog, self-service environments, pipeline status and an assistant that answers from the platform's docs.
Role
Design & Development
Stack
Next.js, Voyage AI, Groq
Type
Internal developer platform
Identity
Amber · Fraunces
1. Overview
Named for the Roman god of gates and transitions, Janus is the front door to a team's services, environments and pipelines. It is the first satellite of Siegfried, and in a way Siegfried's twin: the same vault, RAG and dashboard ideas, turned outward into a portal another team would use.
Everything infrastructural is simulated on purpose. The point is the experience of the flows and an AI assistant applied to a real developer-experience problem, not an infrastructure-as-code engine.
⚠️ The Problem
In most engineering teams the answer to "who owns this service", "how do I get a staging environment" or "why is the pipeline red" lives in a person's head or in a wiki nobody finds. Every question becomes a message to someone.
✓ The Solution
Four pillars behind one door. A catalog for ownership, a self-service form for environments, a pipelines view for status, and an assistant that answers from the platform's own docs and cites them.
2. The Dashboard
The home page was rebuilt so it can be read in one glance without scrolling: two columns, with stat cards and a runs chart on the left and the service and reliability breakdowns on the right. The deltas are labelled in the interface as a synthetic demo series, not hidden in a code comment.
3. The Pillars
Service catalog
Seven services with owner, type, stack and status, in dense rows rather than cards, each with its own detail page.
Self-service provisioning
Pick a service and an environment, and the server streams a provisioning log line by line over server-sent events, ending in a preview URL. Nothing is created, and the screen says so.
Pipelines
Recent CI runs for every service, grouped into running, failed and succeeded, with commit, message, duration and author.
Command palette
⌘K jumps to any page or service and can open the assistant, which lives in a rail on the left that expands on hover instead of taking a tab of its own.
4. The Assistant
The assistant reuses the retrieval pattern from Siegfried, but without its database. Five internal docs make sixteen chunks, which is small enough to embed once, commit as JSON and rank in memory on each question. Groq then writes a short answer from the retrieved excerpts only, and the response lists its sources with their similarity scores.
5. Identity
Benchmarked against Railway, Linear and Port. The base is the same neutral grayscale as Siegfried, and the identity comes from an amber accent reserved for the active state, the primary button and status dots, an italic Fraunces wordmark paired with Plus Jakarta Sans, and dark mode as the default.
First attempt, rejected: A warm cream and terracotta theme that only repainted Siegfried. It became the rule for every later satellite: never differentiate by palette alone.
Structure borrowed, not content: Stat cards with a delta badge, an area chart with a tooltip and segmented status bars, taken as grammar from real dashboards.
6. Outcome
4
pillars
7
services in the catalog
16
doc chunks indexed
0
databases needed
Key Takeaways
- Right-size retrieval: For a few dozen chunks, a JSON file and cosine similarity beat a vector database.
- Simulate honestly: The provisioning flow feels real, and the screen is clear that nothing was created.
- Design from references: The identity improved the moment it was grounded in real products instead of a new palette.
Next steps: Let the assistant trigger actions, such as starting a provisioning run, with a confirmation step.