Example gallery
Five real .flowgo maps, rendered live below with the same
read-only embed used by the
Obsidian,
VS Code,
remark/rehype, and
browser extension
integrations. Click a box with a bold outline to drill into its
submap; the breadcrumb at the top of each plate walks back out, and
the key strip under it counts what is in the file. A map small enough
to be read whole is framed in its plate; the Wardley map and the
Cynefin starter are wider than any plate this page can carry, so
theirs stays a window you drag to pan and scroll to zoom. Any of them
can be your starting point: Create a new map with this
under an example opens a copy of it in the editor, yours to change.
Wardley map
A component value chain positioned on the standard Wardley axes: visibility (vertical — user-facing at top, infrastructure at bottom) against evolution (horizontal — Genesis → Custom-Built → Product → Commodity, labeled along the bottom axis, not floating above the components). The "Live map renderer" box has its own submap — click it to drill into a breakdown of parse → layout → paint, the kind of nested detail a flat Mermaid flowchart can't hold.
- wardley.flowgo
- 807 bytes
- 2 canvases
- 9 nodes
- 2 levels
View .flowgo source
map / node need "Quick, mapped answers" 700 80 4 4 node chatui "Chat interface" 700 220 node maprenderer "Live map renderer" 700 400 node llm "LLM reasoning" 420 400 node gpu "GPU compute" 1000 550 4 8 node storage "Object storage" 1000 660 4 8 edge need chatui edge chatui maprenderer edge chatui llm edge maprenderer storage edge llm gpu text axisTitleY Visibility 10 10 text axisTitleX "Evolution →" 1000 800 text t1 Genesis 110 765 text t2 Custom-Built 400 765 text t3 Product 715 765 text t4 Commodity 1000 765 line yaxis 0 40 0 750 8 line xaxis 0 750 1200 750 8 line div1 300 40 300 750 8 line div2 600 40 600 750 8 line div3 900 40 900 750 8 map /maprenderer node parse "Parse .flowgo" 20 50 node layout "Layout engine" 300 50 node paint "SVG paint" 580 50 edge parse layout edge layout paint
Cynefin: three points
Cynefin's domains aren't a grid you sort things into up front — they
emerge from clustering statements like these, not the other way
around. Three raw statements about how someone might approach a
decision, unlabeled on purpose. (Try grouping them yourself before
you go looking for the "answer.") This is one of flowgo's built-in
starter presets — flowgo new --preset three-points.
- cynefin.flowgo
- 504 bytes
- 1 canvases
- 3 nodes
- 1 levels
View .flowgo source
version 0.3.2 node b1 "It doesn't matter too much what we do, as long as we act decisively, no time for investigation or hypothesis testing" 1416 857 node b2 "We would all know what to do with the benefit of hindsight, but couldn't\nknow in advance - there are multiple coherent ideas about what to do" 750 40 node b3 "It doesn't matter too much what we do, as long as we act decisively, no time for investigation or hypothesis testing" 20 860 nodesize b1 303 132 nodesize b2 266 170 nodesize b3 268 130
flowgo's own architecture
Dogfooding: flowgo mapping itself. The root map shows the site, editor, MCP endpoint, collab layer, and the core format — drill into "flowgo-map.com" or "MCP endpoint" for the actual subsystems underneath each one.
- architecture.flowgo
- 595 bytes
- 3 canvases
- 10 nodes
- 2 levels
View .flowgo source
map / node website flowgo-map.com 340 180 4 4 node editor "Editor (browser)" 660 20 node mcp "MCP endpoint" 660 340 node collab "Live collab (Yjs)" 980 180 node format ".flowgo format + parser" 20 180 4 3 edge website editor edge website mcp edge website collab edge editor format edge mcp format map /website node snapshot "Snapshot store (Postgres)" 20 50 node ogimage "OG-image renderer" 320 50 node share "/m/<id> share link" 170 250 edge snapshot share edge ogimage share map /mcp node createmap "create_map (one-shot)" 20 50 node workspace "start_workspace + incremental tools" 340 50
arc42 Building Block View, three levels deep
arc42 §5 defines the Building Block View as a hierarchy: level 1 is the system as one white box, level 2 zooms into a building block of level 1, level 3 into a building block of that. Most tools render those levels as separate, disconnected pictures that drift apart the moment one of them changes.
Here all three are one file. The root is level 1 — drill into Order Management for level 2, then into Checkout for level 3. The breadcrumb at the top walks back out. Same idea applies to a C4 model: context, container and component are the same nesting under different names.
- arc42.flowgo
- 720 bytes
- 3 canvases
- 13 nodes
- 3 levels
View .flowgo source
map / node customer "Customer (web + app)" 20 200 node oms "Order Management" 340 200 node payment "Payment provider" 660 40 node warehouse "Warehouse / ERP" 660 360 edge customer oms edge oms payment edge oms warehouse map /oms node api "Order API" 20 200 node checkout "Checkout" 320 200 node pricing "Pricing & tax" 620 60 node store "Order store" 620 340 node events "Event bus" 900 200 edge api checkout edge checkout pricing edge checkout store edge checkout events map /oms/checkout node cart "Cart aggregate" 20 180 node rules "Validation rules" 300 40 node reservation "Stock reservation" 300 320 node saga "Payment saga" 580 180 edge cart rules edge cart reservation edge reservation saga edge rules saga
Roadmap
A plain Now / Next / Later board — not every map needs nesting or drill-down; sometimes it's just a clearer way to lay out a list than a bulleted doc.
- roadmap.flowgo
- 363 bytes
- 1 canvases
- 7 nodes
- 1 levels
View .flowgo source
node now1 "Ship llms.txt" 20 100 node now2 "Positioning copy" 20 240 node now3 "Compare page" 20 380 node next1 "Example gallery" 320 100 node next2 "Show HN launch" 320 240 node later1 "Comparison content, expanded" 620 100 node later2 "More agent integrations" 620 240 edge now2 now3 edge now3 next1 text h1 Now 20 40 text h2 Next 320 40 text h3 Later 620 40