# 8StarLabs Full LLM Context
> Great Software Takes Craft. 8StarLabs develops carefully curated software products, shaped through thoughtful design and reliable engineering.
This file is a fuller single-fetch Markdown export for AI assistants, answer engines, and other tools that need clean context about 8StarLabs without parsing the rendered website.
## Entity facts
- Name: 8StarLabs
- Tagline: Great Software Takes Craft
- Type: Independent software studio
- Location: Singapore
- Website: https://www.8starlabs.com
- Contact: hello@8starlabs.com
- Focus: Carefully curated software products, thoughtful product design, reliable engineering, open-source components, architecture tooling, and technical writing.
## Product portfolio
- [8StarLabs UI](https://ui.8starlabs.com): A thoughtfully designed component library built on top of shadcn/ui — featuring unique, production-ready components like status indicators, transport badges, and developer banners to help you build modern interfaces faster. Status: Live, Q4 '25. Audience: Developers.
- [Canopy](https://canopy.8starlabs.com): Canopy turns a repo, integrations, a blueprint or an AI prompt into living architecture maps — with operational metadata, spend tracking, drift detection and AI-ready exports (CLAUDE.md, AGENTS.md). The architecture canvas built for developers. Status: Coming Soon, Q3 '26. Audience: Developers.
## Key source files
- [Concise LLM index](https://www.8starlabs.com/llms.txt)
- [Design system](https://www.8starlabs.com/design.md)
- [Sitemap](https://www.8starlabs.com/sitemap.xml)
- [Robots](https://www.8starlabs.com/robots.txt)
## FAQ
### What does 8StarLabs do?
8StarLabs is an independent software studio focused on building useful, well-designed digital products. That includes in-house tools, SaaS products, open-source projects, and small experiments that solve real problems.
### What does the name 8StarLabs mean?
The name started as a bit of wordplay. The number 8 sounds like “Ba” (八) in Chinese, and Star sounds like “Xing” (星). Put together, it sounds close to “bussin”. The number 8 also carries a sense of luck and growth in Chinese culture, while Star points to craft, direction, and ambition. Labs reflects how the studio works: trying ideas, building quickly, learning from the result, and improving over time.
### Does 8StarLabs take on client work?
Sometimes. Client work is considered selectively, especially when the project has a clear problem, a thoughtful product direction, and room for strong design and engineering. The main focus is still on building in-house products.
### Why does 8StarLabs exist?
8StarLabs exists to make software that feels considered, useful, and pleasant to use. The goal is to keep building products in public, contribute to open-source where it makes sense, and collaborate with people who care about craft.
### Who runs 8StarLabs?
8StarLabs is currently run by https://x.com/keiloktql
### How are new projects chosen?
New projects usually start from a recurring frustration, an underserved workflow, or a small idea that feels worth testing. From there, the idea is researched, prototyped, and refined before it becomes a larger product.
### Is 8StarLabs open to collaboration?
Yes. Collaboration is welcome for open-source work, product experiments, and projects that are a good fit for the studio. For partnership inquiries, reach out to hello@8starlabs.com.
### Where is 8StarLabs based?
8StarLabs is based in Singapore and works remotely. Contributors and collaborators may be based in different places depending on the project.
## Blog and writing
## Architecture as Data: Why Your System Diagram Should Be Structured, Not Drawn
- URL: https://www.8starlabs.com/blogs/architecture-as-data
- Last updated: May 13, 2026
- Summary: Diagrams-as-code was step one. The next step is treating your whole architecture as structured data you own: queryable, diffable, and readable by AI agents. Here's what that means and why it matters.
**In one line:** *Architecture as data* means representing your system as a structured, machine-readable model (nodes, edges, and metadata) instead of a hand-drawn picture. It's the natural successor to diagrams-as-code, and it's what makes an architecture map queryable, diffable, and legible to AI agents.
If you've ever opened a Confluence page, found an architecture diagram, and immediately wondered *"is this still true?"*, this post is about the fix.
# The problem with drawings
A drawing is a snapshot of what one person believed the system looked like on one afternoon. The moment it's saved, reality starts pulling away from it. Nobody's job is to keep it in sync, so it drifts (quietly, invisibly) until someone makes a decision based on a diagram that's a year stale.
This isn't a discipline problem. It's a *representation* problem. You can't diff a PNG. You can't query a Figma board. You can't ask a `.lucid` file "what depends on the payments service?" The format itself makes truth expensive to maintain.
The fix is to change the format.
# Three steps up the ladder
Think of architecture representation as a ladder. Most teams are standing on the first rung.
### Rung 1: Diagrams (pictures)
Lucidchart, Figma, a photo of a whiteboard. Human-made, human-read, drift by default. Fine for a one-off conversation; dangerous as a source of truth.
### Rung 2: Diagrams-as-code (text that renders to a picture)
Mermaid, PlantUML, Structurizr DSL. A big improvement: the diagram lives in Git, renders in pull requests, and diffs as text. But notice what it *is*: you're still authoring a picture. The text describes layout and shapes. There's no first-class concept of "this is a Postgres database that costs $50/mo and is owned by the platform team."
### Rung 3: Architecture as data (a model you render however you like)
Here the source of truth is **structured data**: a list of nodes with types and metadata, a list of edges with direction, groupings, ownership, spend. The picture is just *one view* of that data. Because it's data, you can:
- **Query it:** "show me everything downstream of the auth service."
- **Diff it:** an architecture change is a data change in a PR.
- **Enrich it:** attach cost, environment, status, owner, links to dashboards.
- **Render it many ways:** a flow view, a cost view, a topology, a table.
- **Feed it to machines:** monitoring, docs generators, and AI agents.
Rung 3 is the goal. Diagrams-as-code got us halfway there by putting the *text* in Git; architecture-as-data finishes the trip by making the text a *model* instead of a drawing.
# What "structured" actually buys you
Let's make it concrete. Suppose your architecture is a small JSON document: nodes, edges, and metadata. It might look conceptually like this:
```json title="canopy.json" showLineNumbers
{
"nodes": [
{ "id": "web", "type": "nextjs", "owner": "frontend", "spend": 20 },
{ "id": "api", "type": "node", "owner": "platform", "spend": 60 },
{ "id": "db", "type": "postgres", "owner": "platform", "spend": 50 }
],
"edges": [
{ "from": "web", "to": "api" },
{ "from": "api", "to": "db" }
]
}
```
Now watch what becomes trivial:
- **A cost roll-up** is a `sum` over `spend`. Your architecture diagram just became a FinOps dashboard.
- **A blast-radius query** ("what breaks if `db` goes down?") is a graph traversal. Your diagram just became an incident tool.
- **Ownership routing** ("who do I page for `api`?") is a lookup. Your diagram just became an on-call reference.
- **An agent handoff** is an export. Your diagram just became context for Claude.
None of that is possible with a picture. All of it is trivial with data. That's the whole argument.
Stop asking "what tool draws the nicest diagram?" and start asking "what's my architecture's *source of truth*, and is it structured?" The diagram is just a view. The data is the asset.
# Why this matters more in 2026 than it did in 2020
Two things changed.
**First, systems got more expensive to hold in your head.** The average product is now a dozen managed services, three databases, a queue, a cache, four SaaS integrations, and a bill that arrives from six vendors. No single person knows the whole shape. A drawing can't keep up; a model can.
**Second, you're not the only reader anymore.** AI coding agents now do a huge share of the reasoning about your system, and they're doing it nearly blind, reconstructing architecture one file at a time, every session. Hand an agent a structured map and it stops guessing. This is why "architecture as data" and "agent-ready" have become the same conversation: a model you can export as a [`CLAUDE.md` or `AGENTS.md`](https://canopy.8starlabs.com/docs/maps/exports?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=arch_as_data), or serve over [MCP](https://canopy.8starlabs.com/docs/mcp?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=arch_as_data), is the same asset that keeps your humans honest.
# What this looks like in practice
You don't need to build this from scratch. The pattern is what matters:
1. **Make the map structured data** (nodes, edges, metadata) and put it in version control.
2. **Enrich it** with the operational facts you actually care about: cost, owner, environment.
3. **Render views** for humans (flow, topology, cost) from that one source.
4. **Export it** for machines (agents, docs, monitoring).
This is precisely the model behind **[Canopy](https://canopy.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=arch_as_data)**: every map is a structured document you own, not a drawing. You can import a repo, start from a template, or paste a `canopy.json`, attach spend and ownership, and then export agent-ready context or serve it over MCP. But the idea is bigger than any one tool: **your architecture deserves to be data.**
# FAQ
## What does "architecture as code" mean?
"Architecture as code" (or *architecture as data*) means storing your system's architecture as a structured, version-controlled artifact (a model of nodes, edges, and metadata) rather than a hand-drawn diagram. The visual diagram becomes one rendered view of that underlying data.
## How is this different from diagrams-as-code like Mermaid?
Diagrams-as-code (Mermaid, PlantUML) stores the *diagram* as text, which is a big improvement over binary drawings. Architecture-as-data goes further: the source of truth is a *model* with typed nodes and real metadata (cost, ownership, status), not a description of shapes and layout. You can query and enrich a model in ways you can't with a rendered picture.
## Why should architecture be machine-readable?
Because machines now read it. Monitoring, documentation generators, and especially AI coding agents all benefit from a structured map. A machine-readable architecture can be exported to agent context files (`CLAUDE.md`, `AGENTS.md`) or served over MCP, so your tools reason about the real system instead of guessing.
## Do I have to give up nice-looking diagrams?
No. When architecture is data, the diagram is just one view rendered from it, and it can look great. The difference is that the picture is generated from a source of truth, so it stays in sync instead of drifting.
---
*Want your architecture to be structured data you own, with spend, ownership, and agent-ready exports built in? That's [Canopy](https://canopy.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=arch_as_data), from [8StarLabs](https://8starlabs.com).*
## Give Your AI Coding Agent a Map: How CLAUDE.md, AGENTS.md and MCP Actually Work
- URL: https://www.8starlabs.com/blogs/map-for-your-ai-coding-agent
- Last updated: Jul 2, 2026
- Summary: AI coding agents reconstruct your architecture from scratch every session. Here's how CLAUDE.md, AGENTS.md and MCP give them a real map, and why an accurate one changes everything.
**The short version:** an AI coding agent starts every task nearly blind to your system's shape. `CLAUDE.md` and `AGENTS.md` are plain-text files that hand the agent standing context; **MCP** lets it pull live context on demand. Give it an accurate architecture map through either channel and the quality of its work goes up sharply. This post explains what each one is, when to use which, and how to keep the map from going stale.
# Why your agent keeps guessing
Watch a coding agent work and you'll notice it spends the first chunk of every task *orienting*: grepping for files, opening configs, inferring what talks to what. It's reconstructing your architecture from raw source, one file at a time, from zero, every single session. It has no memory of the map you carry in your head.
That reconstruction is lossy. The agent can see that `api/` imports a Postgres client; it can't see that there are three databases and this one is the *analytics* replica you must never write to. It can see a `stripe` import; it can't see that billing is owned by a different team and changes there need review. The gap between "what's in the code" and "what a senior engineer knows about the system" is exactly where agents make confident mistakes.
The fix is to stop making it guess. Hand it the map.
# The two channels: standing context vs. live context
There are two ways to give an agent context, and they're complementary.
| | Standing context | Live context |
| --- | --- | --- |
| **Mechanism** | `CLAUDE.md`, `AGENTS.md` | MCP server |
| **When it's read** | Every session, automatically | On demand, when the agent asks |
| **Best for** | Stable facts, conventions, the big-picture map | Fresh, queryable, larger data |
| **Freshness** | As fresh as the file | Live at query time |
| **Analogy** | The onboarding doc | Asking a teammate a question |
## CLAUDE.md and AGENTS.md: the onboarding doc
These are just Markdown files in your repo. The agent reads them automatically at the start of a session, so they're the right home for things that are true across many tasks: the tech stack, the directory map, key conventions, and, crucially, **the architecture**. What are the services? What depends on what? Who owns which piece? What must never be touched?
`AGENTS.md` is the emerging cross-tool convention; `CLAUDE.md` is the same idea for Claude-based workflows. Many teams keep both, often with one pointing at the other.
A strong architecture section in one of these files reads less like prose and more like a briefing:
```md title="AGENTS.md" showLineNumbers
## Architecture
- web (Next.js) → api — owned by @frontend
- api (Node) → db, cache — owned by @platform
- db (Postgres, primary) — DO NOT run migrations without review
- analytics-db (Postgres, replica) — READ ONLY
- worker → db, queue — owned by @platform
Payments flow through `api` only. Never call Stripe from `web`.
```
Notice how much of that an agent could *not* have inferred from the code alone. That's the value.
## MCP: asking a teammate a question
The [Model Context Protocol](https://modelcontextprotocol.io) lets an agent call out to a server for context at the moment it needs it. Where `AGENTS.md` is a document the agent reads once, MCP is a *live connection* it can query mid-task: "list the services," "what's downstream of `api`," "what does this cost." It's ideal when the data is large, changes often, or is better queried than dumped into a file.
The two work best together: put the durable big picture in `AGENTS.md`, and wire up MCP for the live, queryable detail.
# The catch nobody mentions: the map has to be *true*
Here's the trap. A hand-written `AGENTS.md` architecture section is a diagram in disguise, and it drifts exactly like every other diagram. You write a beautiful architecture briefing on Monday, ship three services by Friday, and now your agent is confidently reasoning about a system that no longer exists. A *wrong* map is worse than no map, because the agent trusts it.
So the real problem isn't "how do I write an `AGENTS.md`." It's "how do I keep the architecture in it *accurate* without hand-editing it forever." And that lands you right back on the core principle: **the map should be generated from a source of truth, not maintained by hand.**
If a human has to remember to update the architecture in your `AGENTS.md`, it will be wrong within a month. Generate it from structured data instead.
# Closing the loop with a living map
This is the part where the two ideas meet. If your architecture already lives as [structured data](https://canopy.8starlabs.com/docs/maps/architecture-as-code?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=agent_map) (nodes, edges, ownership, spend), then both agent channels come almost for free:
- **Standing context:** export the map to `CLAUDE.md` / `AGENTS.md` and commit it. Regenerate on change so it never drifts.
- **Live context:** serve the same map over an MCP server so agents can query services, dependencies, and cost in real time.
That's exactly how we built **[Canopy](https://canopy.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=agent_map)**: your architecture is a structured map, and it exports [`CLAUDE.md` / `AGENTS.md`](https://canopy.8starlabs.com/docs/maps/exports?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=agent_map) *and* serves a read-only [MCP server](https://canopy.8starlabs.com/docs/mcp?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=agent_map) with tools like `get_architecture`, `list_services`, `get_spend`, and `find_dependencies`. One source of truth, both channels, always current.
You can absolutely hand-roll this. The point isn't the tool, it's the shape: **one accurate, structured map, delivered to your agents through both a file and a live connection.**
# FAQ
## What is a CLAUDE.md file?
`CLAUDE.md` is a Markdown file in your repository that gives Claude-based coding agents standing context about your project: the stack, conventions, directory layout, and architecture. The agent reads it automatically at the start of a session so it doesn't have to reconstruct everything from source.
## What's the difference between CLAUDE.md and AGENTS.md?
They serve the same purpose, persistent context for AI coding agents, but `AGENTS.md` is the emerging tool-agnostic convention adopted across many agents, while `CLAUDE.md` is oriented at Claude workflows. Many teams maintain both, and the content overlaps heavily.
## When should I use MCP instead of an AGENTS.md file?
Use `AGENTS.md` for stable facts the agent should always know. Use **MCP** for context that's large, frequently changing, or better queried than dumped into a file, like live service inventories, dependency graphs, or cost data. In practice you use both: a file for the big picture, MCP for live detail.
## How do I stop my agent context from going out of date?
Don't hand-maintain the architecture section. Generate it from a structured source of truth (a data-backed architecture map) and regenerate on change, or serve it over MCP so the agent always reads the current state. Hand-written architecture docs drift; generated ones don't.
## Does giving an agent architecture context actually improve its output?
Yes, noticeably. Much of an agent's early effort goes into inferring system shape, and its worst mistakes come from inferring it wrong. Supplying an accurate map removes that guesswork, so the agent spends its budget on the actual task and makes fewer architecture-level errors.
---
*Canopy turns your architecture into structured data and exports it straight to `CLAUDE.md`, `AGENTS.md`, and MCP, so your agents always have the real map. Explore [Canopy](https://canopy.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=agent_map) from [8StarLabs](https://8starlabs.com).*
## How I Built a Beat-Synced UI Showcase Video with Remotion and Claude
- URL: https://www.8starlabs.com/blogs/remotion-claude
- Last updated: Mar 29, 2026
- Summary: A behind-the-scenes look at how I used Remotion to create a fast-paced product showcase for 8StarLabs UI components, synchronized to music and polished with cinematic motion.
If you saw this product video on [x.com](https://x.com/keiloktql/status/2038284016600916460), this is the breakdown of how I made it.
I built it to showcase [8StarLabs UI](https://8starlabs.com/ui) as a rhythmic product experience instead of a static demo, using [Remotion](https://www.remotion.dev/) and [Claude](https://claude.ai/) to turn React components into a fully timed video sequence with transitions, sound effects, and scene choreography.
Remotion was the rendering engine, but Claude was the co-director that made the process fast, structured, and surprisingly smooth.
# What I Wanted to Achieve
Most UI promo videos are clean but forgettable. My goal was to make this one feel alive:
- Fast, intentional pacing
- Beat-aligned transitions
- Clear component presentation
- A distinct visual identity across scenes
The final flow highlights components like `Flip Clock`, `Heatmap`, `Partition Bar`, installation flow, and CTA, all stitched together as one cohesive story.
# Why Remotion Was the Right Fit
Remotion gave me a workflow I love: build video like UI.
Instead of keyframing in a traditional editor, I could:
- Drive motion with React logic
- Reuse design tokens and component code
- Centralize timing in shared constants
- Iterate quickly with code-level precision
For a component-first team, this is a huge advantage. Our motion system stays programmable and maintainable.
# Why Claude Made This Smooth
The biggest speedup was not just writing code faster. It was reducing decision fatigue across the entire edit pipeline.
I used Claude to:
- Convert rough ideas into a clean scene-by-scene sequence
- Turn BPM and bar counts into practical timing blocks I could implement directly
- Suggest transition patterns that matched the energy of each scene
- Draft and refine SFX cue maps with concrete offset suggestions
- Help debug visual consistency issues without breaking pacing
Instead of context-switching between planning docs, notes, and code, I could keep one continuous loop: decide, implement, preview, adjust.
# Timing Architecture: One Source of Truth
A major decision was to centralize rhythm and sequencing into shared timing constants:
- FPS
- BPM
- Beat and bar duration
- Scene lengths
- Transition lengths
- SFX cue offsets and trims
Once these were unified, retiming the entire video for a new track became much easier.
When the soundtrack shifted to 97 BPM, I updated core timing and the whole composition stayed coherent.
# Making the Intro Actually Interesting
The intro went through multiple iterations.
I reduced dead time, tightened transitions, and introduced a loading-style progression before component reveals. The result feels more like a product story and less like a static title card.
I also tuned text movement and opacity ranges so the opening remains readable while still feeling dynamic.
# Component Scenes: Clarity First, Style Second
In each showcase scene, I standardized a clearer pattern:
- Component in focus
- Plain component name below
- Direct install command visible from the start
That single structural choice made the video easier to understand, especially for developers seeing the library for the first time.
### Deterministic Rendering: Heatmap Randomness
One of the most useful lessons came from rendering behavior.
The heatmap originally used runtime randomness to generate values. In rendered output, this can introduce unstable visual behavior or run-to-run inconsistencies.
I fixed it by switching to deterministic, seeded random generation per date key.
That preserved the organic look while keeping frames stable and repeatable across renders.
This is one of those small engineering details that makes a big perceived quality difference.
#### Before (runtime randomness, non-repeatable)
```tsx showLineNumbers {11-18}
function generateData(endDate: Date): HeatmapData {
const data: HeatmapData = [];
const curr = new Date(endDate);
curr.setFullYear(curr.getFullYear() - 1);
while (curr <= endDate) {
const dateKey = `${curr.getFullYear()}-${String(curr.getMonth() + 1).padStart(2, "0")}-${String(curr.getDate()).padStart(2, "0")}`;
const d = curr.getDay();
const isWeekday = d > 0 && d < 6;
// Non-deterministic: every run can produce different values
const val = isWeekday
? Math.random() < 0.65
? Math.floor(Math.random() * 8) + 1
: 0
: Math.random() < 0.2
? Math.floor(Math.random() * 3) + 1
: 0;
if (val > 0) {
data.push({ date: dateKey, value: val });
}
curr.setDate(curr.getDate() + 1);
}
return data;
}
```
#### After (seeded randomness per date key, repeatable)
```tsx showLineNumbers {1, 13-20}
import { random } from "remotion";
function generateData(endDate: Date): HeatmapData {
const data: HeatmapData = [];
const curr = new Date(endDate);
curr.setFullYear(curr.getFullYear() - 1);
while (curr <= endDate) {
const dateKey = `${curr.getFullYear()}-${String(curr.getMonth() + 1).padStart(2, "0")}-${String(curr.getDate()).padStart(2, "0")}`;
const d = curr.getDay();
const isWeekday = d > 0 && d < 6;
// Deterministic: same seed -> same value every render
const val = isWeekday
? random(`${dateKey}-weekday-active`) < 0.65
? Math.floor(random(`${dateKey}-weekday-value`) * 8) + 1
: 0
: random(`${dateKey}-weekend-active`) < 0.2
? Math.floor(random(`${dateKey}-weekend-value`) * 3) + 1
: 0;
if (val > 0) {
data.push({ date: dateKey, value: val });
}
curr.setDate(curr.getDate() + 1);
}
return data;
}
```
# Audio and SFX: Small Tweaks, Big Impact
For music, I used the YouTube Audio Library.
Then Claude became the audio planner: I provided the exact BPM and scene order, and it helped map SFX placement so cues and transitions stayed beat-synced.
I layered in swipe, pop, and typing SFX to support scene changes and interaction cues.
Then I tuned:
- Trigger offsets
- Asset trims
- Per-scene volume
- Cue timing relative to transition motion
Micro-adjustments of just a few frames made transitions feel dramatically tighter, and Claude helped surface many of those timing tweaks faster than manual trial-and-error.
This can be improved further by integrating [ElevenLabs](https://elevenlabs.io/) for voiceover and a more unified audio pipeline.
# Visual Polish Decisions
To avoid generic template motion graphics, I leaned into a specific style language:
- High-contrast cards
- Animated rainbow shimmer outlines
- Distinct palette cycles per scene
- Soft 3D depth and shadow stacks
- Minimal typography treatment inspired by product-launch aesthetics
The key was balancing energy with readability so style never hid the message.
# What I Learned
Building promo video in code is not just possible, it is often better for product teams, especially when AI is part of the workflow:
1. Motion becomes versionable and repeatable
2. Timing can be retuned globally in minutes
3. Claude reduces planning overhead and iteration friction
4. Visual and engineering systems stay aligned
5. Render output quality improves when randomness is controlled
If your product already lives in React, combining Remotion with Claude is a powerful way to ship marketing visuals without breaking your development workflow.
# Try It Yourself
If you are building a component library or product UI and want a video showcase that feels custom, not canned, this workflow is worth exploring.
Start with a small sequence:
- One intro
- Two component scenes
- One CTA
Then centralize timing, add audio cues, and iterate by feel.
That is where the magic happens.
## I Stopped Drawing Architecture Diagrams. Here's What I Do Instead.
- URL: https://www.8starlabs.com/blogs/i-stopped-drawing-architecture-diagrams
- Last updated: Jun 18, 2026
- Summary: A personal story about years of maintaining architecture diagrams nobody trusted, and the shift to living, structured maps that finally stayed true. Lessons from building at 8StarLabs.
I used to be the person who drew the diagrams.
You know the one. New engineer joins, asks "how does the system fit together?", and everyone turns to look at me. So I'd open Lucidchart, spend an hour rebuilding the picture from memory, drop it in Notion, and feel briefly like a responsible adult. Two months later that same picture would be quietly, confidently wrong, and I'd draw it again.
This is the story of how I stopped doing that.
# The diagram graveyard
At one point I counted. Across our wiki, our repos, and three different whiteboarding tools, we had **eleven** architecture diagrams. Not one of them agreed with another. Not one of them matched production.
There was the "official" one in Confluence, last edited eight months ago. There was a FigJam board from an offsite that had four services we'd since deleted. There was a Mermaid block in a README that was *almost* right, which is the most dangerous kind of wrong. And there was a photo of a whiteboard in someone's Slack DMs that, honestly, was probably the most accurate of the lot.
The diagrams weren't the problem. The *format* was. Every one of them was a picture, a thing a human had to remember to update, by hand, forever. Nobody's OKRs said "keep the architecture diagram in sync." So nobody did. And I couldn't blame them, because I didn't either.
# The moment it clicked
The click came during an incident.
Payments were failing. We were nine people on a call at 1am trying to reconstruct, from memory, what actually talked to the payment provider. Someone pulled up the Confluence diagram. It showed a service that had been decommissioned in Q1. We lost twenty minutes chasing a ghost.
When it was over, I wasn't angry about the outage. I was angry that we had *eleven diagrams* and not one of them could answer a simple question: **what depends on this thing?**
That's when it hit me. I didn't need a better drawing. I needed the architecture to be something I could *query*. A picture can't answer "what's downstream of payments." A data structure can, instantly.
I'd been treating architecture as a *drawing problem*. It was a *data problem* wearing a drawing's clothes.
# What I do now
These days I don't draw architecture. I model it. The rules I settled on are boring and that's the point:
- **One source of truth, and it's structured.** The architecture is a data file (nodes, edges, metadata) that lives in version control. Not a picture. A model.
- **The picture is generated, never hand-maintained.** If I want a visual, it renders from the data. When the data changes, the picture changes. There is no separate thing to forget.
- **Operational facts ride on the map.** Each service carries what it costs, who owns it, and what environment it's in. The map isn't just topology; it's the thing I actually reach for during an incident or a cost review.
- **The machines get a copy.** Our AI coding agents read an exported version of the map. They stopped guessing at our architecture, which made them dramatically more useful.
The eleven diagrams collapsed into one living map. And for the first time, the answer to "is this still true?" was just *yes*.
# The part where I admit I built a product about this
I'll be honest about the arc here, because this is a personal blog and you can smell a pitch coming a mile off.
I got obsessed with this problem, and obsession is how products get made. My team at [8StarLabs](https://8starlabs.com) ended up building **[Canopy](https://canopy.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=stopped_drawing)**, an architecture canvas where every map is structured data you own, not a drawing. You point it at a repo (or a template, or a `canopy.json`), it maps your services, you attach spend and ownership, and then (the part I care about most) you can export a [`CLAUDE.md` / `AGENTS.md`](https://canopy.8starlabs.com/docs/maps/exports?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=stopped_drawing) for your agents or serve the whole thing over [MCP](https://canopy.8starlabs.com/docs/mcp?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=stopped_drawing).
It's the tool I wish I'd had on that 1am call. But whether or not you ever use it, take the lesson for free: **the diagram is not the asset. The data is.**
# If you're standing in a diagram graveyard right now
Here's the smallest possible first step, no tooling required:
1. Pick your most-referenced diagram. The one people actually open.
2. Ask it a question you'd ask during an incident (*"what depends on X?"*) and notice that it can't answer.
3. Write the same architecture down as structured text instead: a list of services and what they connect to. Commit it.
That's it. You've just moved one rung up, from a picture nobody trusts to data you can build on. Everything else, including whether you ever adopt a dedicated tool, follows from that one move.
I drew my last architecture diagram a while ago now. I don't miss it. The system finally has a map that tells the truth, and I got my 1am back.
---
*Kei Lok is Lead Engineer at [8StarLabs](https://8starlabs.com), where the team builds [Canopy](https://canopy.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=stopped_drawing) and [8StarLabs UI](https://ui.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=stopped_drawing). Say hi on [X](https://x.com/keiloktql).*
## Introducing 8StarLabs UI: Open-source react component library
- URL: https://www.8starlabs.com/blogs/8starlabs-ui
- Last updated: Dec 3, 2025
- Summary: 8StarLabs UI is an open-source React component library built on top of shadcn/ui, designed to help you build interactive and unique interfaces faster.
We’re thrilled to introduce **[8StarLabs UI](https://ui.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=8sl_intro_blog)**, an open-source React component library designed to help developers and designers **build modern, interactive, and unique interfaces faster**.
# Why 8StarLabs UI?
Across countless projects, we realized a problem: most component libraries focus on **generic, everyday components** like buttons, forms, and modals, things that have already been implemented countless times. While these components are useful, they don’t help your project stand out.
With **8StarLabs UI**, our goal is different. We focus on **building special, niche components**, UI elements that solve uncommon problems and elevate your interfaces. These aren’t your typical buttons or input fields. From **interactive dashboard elements** to **custom status indicators**, we create components designed to **make your project unique** and handle cases you won’t find in standard libraries.
By combining these niche components with the power of shadcn/ui, 8StarLabs UI allows you to:
- **Develop Faster:** Add complex, uncommon components without reinventing the wheel.
- **Stand Out Visually:** Deliver interfaces that feel distinctive and memorable.
- **Scale Smartly:** Modular components integrate seamlessly with your existing Next.js stack.
We're starting with **3 carefully crafted components** today, with many more exciting additions planned. Each component has been designed to solve real problems we've encountered in production applications.
# Why We Chose the Shadcn Registry
Instead of publishing to npm, we decided to use the **shadcn registry** for our components. This approach lets us:
- **Ship Components Instantly:** No waiting for npm releases; new components are ready as soon as they’re published.
- **Offer Version Flexibility:** Pick only the components you need, without worrying about version conflicts.
- **Seamlessly Integrate:** Components work directly with shadcn/ui, making adoption effortless for projects already using it.
This setup ensures our **niche components reach developers quickly** and integrate cleanly into real projects.
## Shadcn MCP Capabilities
Another reason we chose the shadcn ecosystem is its [MCP (Model Context Protocol)](https://modelcontextprotocol.io/docs/getting-started/intro) capabilities, a forward-looking feature that allows **AI assistants to interact directly with component registries**.
The [shadcn MCP Server](https://ui.shadcn.com/docs/mcp) enables developers (or AI copilots) to:
- **Browse available components** from any registry.
- **Search and install** them directly into your project using natural language.
For example, you can ask your AI assistant:
> “Find me a transport badge from the 8starlabs registry.”
Registries are configured in your project’s `components.json` file:
```json title="components.json" showLineNumbers
{
"registries": {
"@8starlabs-ui": "https://ui.8starlabs.com/r/{name}.json"
}
}
```
# Contributing
8StarLabs UI is open-source and community-driven. If you want to contribute:
1. Check out the contributing guide
2. Report issues or suggest new components
3. Star the project on [GitHub](https://github.com/8starlabs/ui)
We love seeing what the community builds using 8StarLabs UI!
# Getting started
Components are available via the shadcn install command.
```bash
npx shadcn@latest add
```
For example, to install the Status Indicator component, you can run:
```bash
npx shadcn@latest add https://ui.8starlabs.io/r/status-indicator.json
```
[Read the docs](https://ui.8starlabs.com/docs?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=8sl_intro_blog) and start building beautiful interfaces, faster.
## Introducing Canopy: The Living Map of Your Stack
- URL: https://www.8starlabs.com/blogs/introducing-canopy
- Last updated: May 29, 2026
- Summary: Canopy turns a repo, integrations, a template or an AI prompt into a living architecture map, with spend tracking, ownership, and agent-ready exports like CLAUDE.md, AGENTS.md and MCP. Meet the architecture canvas built for developers.
We're excited to introduce **[Canopy](https://canopy.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=canopy_intro)**, the architecture canvas built for developers. Canopy turns your stack into a **living architecture map**: every service, what it costs, and who owns it, in one picture you can actually trust, and that your AI agents can finally read.
# Why we built Canopy
Every team has the same broken ritual. Someone draws an architecture diagram. It's beautiful for about a week. Then the system changes, the diagram doesn't, and within a month you're making decisions off a picture that's quietly wrong.
The root cause isn't laziness. It's the format. A diagram is a *drawing*: a thing a human has to remember to update by hand, forever. You can't diff it, you can't query it, and no machine can read it.
Canopy fixes this by changing the format. **Every map in Canopy is structured data you own, not a drawing.** That one shift is what makes everything else possible: cost roll-ups, dependency queries, and exports your coding agents can consume.
# What Canopy does
Canopy is organized around four verbs: **Capture. Visualize. Operate. Share.**
## Capture: get a map in minutes, not hours
You don't start from a blank canvas unless you want to. Canopy can populate a map from:
- **A GitHub repo**: install the Canopy GitHub App and it detects services from your `package.json`, lockfile, and infra files.
- **An integration catalog**: search 200+ services and hand-pick your stack.
- **A template**: start from a real, editable community map.
- **A `canopy.json` file**: paste a structured map and go.
- **Canopy AI**: describe your system in plain English and get a draft map.
## Visualize: a picture that stays true
Because the map is data, the diagram is just one *view* of it. Canopy gives you interactive [React Flow](https://reactflow.dev) maps, workspace topology, and cost-domain views, and when the data changes, the picture changes with it. No more stale drawings.
## Operate: architecture that knows what it costs
This is where a Canopy map stops being a diagram and becomes an operational tool. Attach **spend** to each service and Canopy rolls it up per map and across your workspace. Add ownership, environments, and operational metadata. Your architecture diagram just became a FinOps and on-call reference at the same time.
## Share: publish, or sell
Make a map public, share a private link, or list it as a **paid template** in the marketplace with Stripe Connect payouts. Verified workspaces get a seal and provenance-stamped clones.
# The part we care about most: your agents get the map
Here's the feature that changes how it feels to work day to day. Your AI coding agents (Claude, Cursor, whatever you run) currently reconstruct your architecture from scratch every session, one file at a time, and they get it wrong in exactly the places a senior engineer wouldn't.
Canopy closes that gap. Because your map is structured data, Canopy can:
- **Export [`CLAUDE.md` and `AGENTS.md`](https://canopy.8starlabs.com/docs/maps/exports?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=canopy_intro)** so your agents get the architecture as standing context.
- **Serve a read-only [MCP server](https://canopy.8starlabs.com/docs/mcp?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=canopy_intro)** with tools like `get_architecture`, `list_services`, `get_spend`, and `find_dependencies`, so agents can query the live map on demand.
One source of truth, delivered to your team *and* your tools.
Canopy makes your architecture structured data you own, so the picture stays true, the costs roll up, and your agents finally know your system.
# Getting started
The Free plan is enough to draw your first living map:
1. Sign up at **[canopy.8starlabs.com](https://canopy.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=canopy_intro)**.
2. Create a map: import a repo, pick integrations, or start from a template.
3. Draw the connections and attach spend and ownership.
4. Export a `CLAUDE.md` for your agents, or share a public link.
Read the [quickstart](https://canopy.8starlabs.com/docs/quickstart?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=canopy_intro) to go from zero to a living map in about two minutes.
# This is just the start
On the roadmap: live metadata sync, deeper AI architecture analysis, cost-optimization recommendations, graph querying, and agent-native payments. Canopy is part of a bigger belief at [8StarLabs](https://8starlabs.com): that developer tools should be built for both the humans *and* the agents now working side by side.
If your architecture deserves to be more than a stale drawing, come map it.
[Try Canopy free](https://canopy.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=canopy_intro). And if you build interfaces, check out our open-source component library, [8StarLabs UI](https://ui.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=canopy_intro), too.
## The Best Software Architecture Diagramming Tools in 2026 (Compared)
- URL: https://www.8starlabs.com/blogs/architecture-diagramming-tools-2026
- Last updated: Apr 22, 2026
- Summary: A practical, no-fluff comparison of the top software architecture diagramming tools in 2026 (Lucidchart, Excalidraw, Eraser, IcePanel, Mermaid, Structurizr, Figma and Backstage), plus when a diagram is the wrong tool entirely.
**Short answer:** the best software architecture diagramming tool in 2026 depends on what you're optimising for. Pick **Excalidraw** for a quick whiteboard sketch, **Mermaid** or **Structurizr** for diagrams that live in Git, **Lucidchart** for polished stakeholder decks, **IcePanel** for C4 models, and **Figma** when the diagram is really a design artifact. If you want the diagram to stay *accurate* six months from now (and to be readable by your AI coding agents), you probably want an [architecture map that's backed by structured data](https://canopy.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=arch_tools_2026) rather than a drawing.
This post breaks down the trade-offs so you can choose without a week of trials.
# What to actually look for in an architecture tool
Most "top 10 diagramming tools" lists are just feature checklists. The features that matter in practice are narrower than that. Before you look at any tool, decide where it lands on these five axes:
- **Drawing vs. data.** Is the output free-form shapes, or a structured model you can query, diff and export? This is the single biggest fork in the road.
- **Drift resistance.** How much manual work does it take to keep the diagram true after the system changes? A beautiful diagram that's wrong is worse than no diagram.
- **Collaboration.** Real-time multiplayer, comments, and sharing without a login wall.
- **Version control.** Can the diagram live in a pull request and be reviewed like code?
- **Machine-readability.** Can an LLM or coding agent consume the output? In 2026 this is no longer a nice-to-have: your agents need to know your system.
Hold those five in mind as you read. Here's how the popular tools stack up.
# The 2026 lineup, compared
| Tool | Best for | Model | Lives in Git | Drift resistance |
| --- | --- | --- | --- | --- |
| Excalidraw | Fast, disposable sketches | Freehand | Sort of (`.excalidraw` JSON) | Low |
| Lucidchart | Stakeholder-ready diagrams | Shapes | No | Low |
| Figma / FigJam | Design-adjacent diagrams | Shapes | No | Low |
| Mermaid | Diagrams-as-code in Markdown | Text → graph | Yes | Medium |
| Structurizr | C4 model, one source of truth | DSL / code | Yes | Medium-high |
| IcePanel | C4 with a friendly UI | Structured C4 | Partial | Medium-high |
| Backstage | Service catalog + software templates | Data (catalog) | Yes | High (if fed) |
| Canopy | Living map with spend + agent exports | Structured data | Yes (`canopy.json`) | High |
Now the detail.
## Excalidraw: the whiteboard everyone reaches for
Excalidraw is the fastest way to get a shape on a canvas, and the hand-drawn look keeps early diagrams feeling appropriately provisional. It's free, open-source, and the `.excalidraw` file is JSON you can commit. But it's a *drawing*: nothing stops the boxes from lying, and there's no notion of "this box is a service that costs $/mo and depends on that one." Reach for it to think, not to document.
## Lucidchart: polished, corporate, and stale by Friday
Lucidchart is the incumbent for a reason: templates, shape libraries, integrations, and output that looks great in a slide. The catch is the classic one: someone spends an afternoon making the diagram beautiful, ships it, and it's out of date the moment the next PR merges. Great for a point-in-time artifact for non-engineers; painful as a living source of truth.
## Figma / FigJam: when the diagram is really design
If your team already lives in Figma, FigJam is a low-friction place to sketch flows collaboratively. It's excellent at fidelity and terrible at truth: it has no idea what a "database" or an "edge" means. Use it when the diagram is a communication artifact, not a system model.
## Mermaid: diagrams-as-code, in your Markdown
Mermaid lets you write a diagram as text inside a code block, which means it lives in your repo, renders on GitHub, and diffs in a pull request. That's a real step up on drift resistance. The limits show up as diagrams grow: layout gets fiddly, and you're still describing a *picture*, not a model with cost or ownership attached. For small, in-README diagrams it's hard to beat.
## Structurizr: the C4 purist's choice
Structurizr, from C4-model author Simon Brown, treats architecture as a single model you render into multiple views (context, container, component). Define once, view many ways. If you're committed to C4 and want rigor, it's the most principled option here. The trade-off is a learning curve and a DSL your whole team has to adopt.
## IcePanel: C4 without the DSL tax
IcePanel gives you the C4 discipline with a friendlier collaborative UI, so non-DSL folks can contribute. It's a strong middle ground for teams that want structured, layered architecture without writing model code. Pricing and the hosted model are the main things to weigh.
## Backstage: a catalog, not a canvas
Spotify's Backstage isn't a diagramming tool; it's a developer portal with a software catalog. If you invest in feeding it, it becomes a living inventory of services and ownership, which is closer to the real goal than any drawing. The cost is exactly that investment: Backstage is a platform you operate, not a tool you open.
# The pattern hiding in this list
Read the table again and one axis quietly predicts everything else: **drawing vs. data.**
Every tool near the top produces *pictures*. Pictures are made by hand, so they drift by default: keeping them true is manual, unpaid, and always the first thing to slip. Every tool near the bottom produces *a model*: structured data that knows what a node is, what depends on what, and (sometimes) what it costs and who owns it.
Once your architecture is data instead of a drawing, three things you couldn't do before become trivial:
1. **Diff it.** An architecture change shows up in a pull request like any other change.
2. **Attach real metadata.** Spend, ownership, environment, and status ride along on each node.
3. **Feed it to machines.** Your monitoring, your docs, and, increasingly, your AI coding agents can read it.
That last point is the one most 2026 tool round-ups still miss.
# The 2026 wrinkle: your AI agents need the map too
Here's what changed. You're no longer the only reader of your architecture. Claude, Cursor, and every coding agent on your team are constantly trying to reason about a system they can only see one file at a time. A stale Lucidchart PDF is useless to them. A structured map they can query is gold.
This is exactly the gap **[Canopy](https://canopy.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=arch_tools_2026)** was built for. Canopy treats your architecture as structured data you own (import a repo, pick integrations, or start from a template), then attaches spend and ownership to every service. Because it's data, not a drawing, it can export a `CLAUDE.md` or `AGENTS.md` for your agents, or serve the whole map over an [MCP server](https://canopy.8starlabs.com/docs/mcp?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=arch_tools_2026) so your tools can read it live. It sits at the bottom-right of that table on purpose: high drift resistance, machine-readable, versionable.
You don't have to switch to it to take the lesson: **if you want your architecture to stay true, stop drawing it and start modeling it.**
# FAQ
## What is the best free architecture diagramming tool?
For free-form sketching, **Excalidraw** is the best free option: open-source, no login required, and the file is JSON you can commit. For diagrams that live in Git, **Mermaid** is free and renders natively on GitHub. If you want structured, agent-readable maps with a free tier, [Canopy](https://canopy.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=arch_tools_2026) offers one.
## What's the difference between a diagram and an architecture model?
A **diagram** is a picture: shapes and lines a human arranged. An **architecture model** is structured data that knows what each element *is* (a service, a database, a dependency) and can carry metadata like cost and ownership. Models can be diffed, queried, and read by machines; diagrams generally can't.
## How do I keep architecture diagrams from going out of date?
Stop maintaining a picture by hand. Move to an approach where the architecture is **structured data that lives in version control**: diagrams-as-code (Mermaid, Structurizr) or a data-backed map (Canopy, a fed Backstage). Then changes show up in pull requests and drift becomes visible instead of silent.
## Can AI coding agents read my architecture diagram?
Not a `.png` or a Lucidchart link: those are opaque to an LLM. Agents can read **structured, text-based** representations: a Mermaid block, a `CLAUDE.md`/`AGENTS.md` file, or a map served over MCP. That's why data-backed tools have a real edge in 2026.
## Is C4 still worth learning?
Yes. The C4 model (Context, Containers, Components, Code) is a durable way to think about architecture at different zoom levels, and tools like Structurizr and IcePanel implement it well. C4 is about *how you structure the model*: it pairs naturally with any data-backed approach.
---
*Building something and want your architecture to stay true, for your team and your agents? Take a look at [Canopy](https://canopy.8starlabs.com?utm_source=8starlabs.com&utm_medium=referral&utm_campaign=arch_tools_2026), the living map of your stack. It's a product of [8StarLabs](https://8starlabs.com).*
## External product URLs
- 8StarLabs UI: https://ui.8starlabs.com
- Canopy: https://canopy.8starlabs.com
## Social URLs
- GitHub: https://github.com/8starlabs
- LinkedIn: https://www.linkedin.com/company/8starlabs/
- X: https://x.com/8starlabs
- Instagram: https://www.instagram.com/8starlabs/
- TikTok: https://www.tiktok.com/@8starlabs_sg