BoardSnap is an iOS app that reads a data flow diagram whiteboard — external entities, processes, data stores, and labeled flows — and produces a structured technical data flow summary for engineering documentation.
Data flow diagrams are a staple of technical design sessions. Before a team builds a new integration, API, or data pipeline, they sketch the DFD on a whiteboard: where does data come from, what processes transform it, where does it live, where does it go. The whiteboard DFD is the shared technical mental model — engineers, PMs, and sometimes security or compliance reviewers are all in the room looking at the same picture.
The DFD needs to become technical documentation. Security reviews require it. New engineers need it to understand the system. Compliance audits ask for it. But the whiteboard DFD is drawn in a shorthand that makes sense to the people in the room and nobody else. Turning it into clean documentation — with entities, processes, and flows described consistently — requires a technical writer or an engineer who already understands the system.
Most teams don't have a technical writer. The engineer who drew the DFD is the one who needs to document it. That engineer would rather be writing code.
External entities — sources and destinations of data outside your system — are drawn as rectangles at the edges of the board. Label each one: 'User,' 'Payment Gateway,' 'Third-party API,' 'Admin.' External entities are the starting and ending points of all data flows.
Processes — transformations that happen inside your system — are drawn as circles or rounded rectangles in the center of the board. Label each one with a verb-noun pair: 'Validate Request,' 'Generate Report,' 'Store User Session.' Number each process: 1.0, 1.1, 2.0, etc. for reference.
Data stores — databases, caches, queues, files — are drawn as two parallel horizontal lines (open-ended rectangle). Label each one with the store name: 'Users DB,' 'Redis Cache,' 'S3 Bucket,' 'Message Queue.' The store label should match how it's named in the system.
Arrows connect entities, processes, and stores. Each arrow represents a data flow. Label every arrow with the data it carries: 'Authentication token,' 'User profile JSON,' 'Payment confirmation,' 'Error response.' Unlabeled arrows are ambiguous — label all of them.
Draw a dashed box around processes that operate in the same trust zone. Trust boundaries separate zones with different security or permission levels. This is required for threat modeling. Label each boundary: 'Public internet,' 'Internal network,' 'Secure enclave.'
For flows that carry sensitive data (PII, payment data, credentials), mark the arrow with a classification label: PII, PCI, CONFIDENTIAL. These are required for compliance documentation and security review.
Open BoardSnap. The DFD has rectangles (external entities), circles (processes), parallel-line shapes (data stores), labeled arrows, trust boundary dashes, and classification markers. BoardSnap AI reads the DFD elements and their relationships.
A structured technical data flow summary: external entities listed, processes listed with their process numbers, data stores listed, data flows described as 'Source → Flow label → Destination' statements, trust boundaries described, and sensitive data flows flagged by classification. The output is the first draft of a system data flow section in a technical design doc, a security review document, or an API specification.
The team drew a DFD for a new payment integration before writing a line of code. Four external entities, six processes, two data stores. The diagram revealed that payment card data would pass through two internal processes before reaching the payment processor — both needed PCI compliance scoping. BoardSnap captured the DFD. The security review used the output directly in the threat model.
The data engineering team drew the pipeline DFD: source systems, transformation processes, intermediate stores, and the analytics data warehouse as the destination. BoardSnap produced a technical description of each flow. The data team used it as the base for pipeline monitoring specifications.
A SOC 2 audit required system data flow documentation the startup didn't have. The CTO and lead engineer spent two hours drawing DFDs for the three main data flows. BoardSnap produced the structured summaries. The compliance team used the output to produce the audit-ready data flow documentation. Three boards, two hours, zero formal documentation backlog remaining.
Yes — shape type is part of the DFD reading. Circles and rounded rectangles are read as processes. Rectangles as external entities. Parallel horizontal lines as data stores. Consistency in your shape conventions is what makes the output accurate — use the same shapes for the same element types throughout the diagram.
Level 0 is a single process showing the system boundary with external entities — very high-level. Level 1 breaks the single process into sub-processes. BoardSnap reads both; more detail in the diagram produces more detail in the output. Level 0 diagrams are simpler to snap and read; Level 1 diagrams require step-back distance to fit the full diagram in frame.
DFDs focus on data flows — what data moves where. Architecture diagrams focus on system components and their relationships — what services or infrastructure exist. They're complementary. Draw the architecture diagram first to establish the components, then the DFD to specify the data flows between them. Snap both in the same BoardSnap project.
Snap the board, ship the action items in ten seconds.