BoardSnap is an iOS app that reads a system architecture whiteboard — components, connections, technology labels, and deployment zones — and produces a structured technical architecture summary in one snap.
System architecture diagrams are born on whiteboards. When an engineer is explaining a system to a new team member, they pick up a marker. When a team is debating how to add a new service, they sketch on the board. When a CTO is presenting the technical strategy to the board, they draw boxes and arrows. The whiteboard is where technical understanding is created and shared.
The problem is that engineering documentation is perpetually out of date. Architecture docs in Confluence were accurate six months ago. The whiteboard session from Tuesday reflects the current state of the architecture. Getting from Tuesday's whiteboard to an updated Confluence page requires someone to sit down and redraw the diagram in Lucidchart, Mermaid, or draw.io — and write the description to match.
That work doesn't happen consistently. The result is architecture documentation that's not trusted, not referenced, and not maintained. New engineers read the doc and then ask a senior engineer 'is this actually how it works?' The senior engineer says 'mostly, but there's a service we added in Q2 that's not in there.' The doc is theater.
Before drawing components, draw a boundary box for the system scope. What's inside the system and what's external? Label external systems at the edges — third-party APIs, user browsers, mobile clients, partner services. The boundary prevents the diagram from expanding indefinitely.
Each major component — service, database, cache, queue, CDN, load balancer — gets a labeled box or icon. Write the component name and, in smaller text below, the technology: 'Auth Service / Node.js,' 'User DB / PostgreSQL,' 'Cache / Redis.' Technology labels are essential for the documentation output.
Arrows between components show connections. Label each arrow with the protocol or mechanism: 'REST/HTTPS,' 'gRPC,' 'WebSocket,' 'SQS message,' 'SQL query,' 'TCP.' Unlabeled arrows are meaningless in an architecture diagram — they show that something connects but not how.
Group components by deployment zone with a dashed box or a different background region. Zones might be: 'Public subnet,' 'Private subnet,' 'On-premises,' 'CDN edge,' 'Mobile client.' Label each zone. This information is critical for security and networking documentation.
For components that have redundancy or auto-scaling, mark them: 'Auto-scales 2-20 instances,' 'Multi-region: us-east-1, eu-west-1,' 'Active-passive failover.' These notes are often missing from architecture docs and are essential for operations teams.
For each major user action or data flow, draw a numbered path through the architecture. Number 1 = API request; number 2 = auth check; number 3 = database query; etc. These numbered paths are how engineers explain the system. BoardSnap reads them as named flows.
Open BoardSnap. Step back far enough to get all components in frame. Complex architectures may require two snaps — one for the full overview and one for a zoomed section. BoardSnap AI reads component names, technology labels, connection protocols, deployment zones, and numbered flows.
A structured architecture description: components listed with their technology stacks, connections described as 'Component A talks to Component B via [protocol],' deployment zones described with their component membership, scaling and redundancy notes per component, and numbered traffic flows described as step sequences. The output is the first draft of an architecture overview document — paste it into Confluence, a README, or an RFC.
The platform team spent three hours at the whiteboard designing a new microservice architecture for a monolith decomposition. Eleven services, four databases, two queues, one CDN. BoardSnap produced the architecture summary. The tech lead used it as the base for the RFC that went to the broader engineering team for review.
The CTO snapped the current system architecture whiteboard from the team room. BoardSnap produced a description that became part of the engineering onboarding guide. Every new engineer read the summary and could immediately understand how the system was structured — without a dedicated 90-minute walkthrough from a senior engineer.
Before a cloud migration, the team drew the current architecture on one board and the target architecture on another. BoardSnap produced summaries of both. The delta between the two summaries became the migration task list.
BoardSnap AI reads labels, not icons. If you draw a cloud icon and don't label it, the output won't know what it is. Write the service name next to any icon: 'AWS Lambda,' 'GCP Cloud Run,' 'S3.' The text is what the output is based on — icons are visual context for humans in the room.
Snap a high-level overview board first. Then snap detail boards for each major subsystem. Store all boards in the same BoardSnap project. The AI chat can answer questions that span multiple boards — 'how does the auth service connect to the notification service?' will pull from whichever board each lives on.
Not directly — BoardSnap produces structured text. But the text output describes the components and connections clearly enough to convert to Mermaid syntax manually in a few minutes. The component list and connection list in the output map directly to Mermaid graph nodes and edges.
Snap the board, ship the action items in ten seconds.