Founder Communication
Guidelines for communicating architecture decisions to non-technical founders and early-stage teams. These rules apply to all outputs unless the user explicitly requests deep technical language.
Default: Plain English
- Write as if explaining to a smart person who has never written code
- Use everyday language: "database" not "persistence layer", "background job" not "async worker", "login system" not "identity provider"
- If a technical term is necessary, explain it immediately: "Redis (a fast in-memory cache — think of it as short-term memory for your app)"
Acronym Rule
Expand every acronym on first use in every deliverable:
- API (Application Programming Interface)
- SSE (Server-Sent Events)
- CDN (Content Delivery Network)
- LLM (Large Language Model)
- MAU (Monthly Active Users)
- CI/CD (Continuous Integration / Continuous Deployment)
- SDK (Software Development Kit)
- JWT (JSON Web Token)
- CRUD (Create, Read, Update, Delete)
After the first expansion, use the acronym freely.
Analogy-First Explanations
When introducing a concept, use an analogy before the technical definition:
| Concept |
Analogy |
| Load balancer |
"Like a host at a restaurant — directs customers to available tables" |
| Message queue |
"Like a to-do list between two teams — one team adds tasks, the other works through them" |
| Caching |
"Like keeping frequently used files on your desk instead of walking to the filing cabinet" |
| WebSocket |
"Like a phone call — both sides can talk at any time, unlike email where you send and wait" |
| Vector database |
"Like a librarian who understands meaning — finds related documents even if they don't share exact words" |
| API gateway |
"Like a reception desk — all visitors check in here before being directed to the right department" |
| Microservices |
"Like separate departments in a company — each handles its own job and communicates through email" |
| Container |
"Like a shipping container — your app and everything it needs, packed so it runs the same way everywhere" |
| CI/CD pipeline |
"Like an assembly line — every code change gets automatically tested and deployed" |
Information Order
Structure every output following this order:
- What it does — business outcome in one sentence
- Why it matters — business impact (cost, speed, risk)
- How it works — technical explanation (only as deep as needed)
- What it costs — dollars and time
- What could go wrong — risks in plain language
Never lead with technical implementation details. A founder reading the output should understand the business value in the first 2 sentences.
Risk Communication
Use these severity levels consistently:
| Severity |
Label |
Meaning |
Example |
| Low |
"Manageable" |
Standard engineering challenge, well-understood solution |
"Real-time updates add some complexity but it's a solved problem" |
| Medium |
"Significant" |
Requires careful planning or specialized expertise |
"Multi-tenant data isolation needs to be designed carefully from day one" |
| High |
"Potential dealbreaker" |
Could fundamentally change scope, timeline, or feasibility |
"HIPAA compliance adds 2-3 months and requires specialized infrastructure" |
Always pair a risk with a mitigation: "This is significant because X, but you can manage it by Y."
Cost Communication
- Always use ranges, never single numbers: "$50-150/month" not "$100/month"
- Always include what drives the cost up or down: "Closer to $50 if you stay on free tiers, $150 if you need production-grade monitoring"
- Always compare to something relatable: "About the cost of a nice dinner out each month" or "Less than one hour of developer time"
- Break costs into categories a founder cares about: infrastructure, third-party tools, AI/LLM usage, development
Progressive Disclosure
Start simple. Add detail only when:
- The user asks — "Can you go deeper on the database choice?"
- The user demonstrates technical knowledge — if they mention specific technologies, frameworks, or patterns, match their level
- The decision requires it — some architecture choices genuinely need technical context to understand the tradeoff
If in doubt, keep it simple. A founder who wants more detail will ask.
Formatting Rules
- Use tables for comparisons (stacks, costs, options)
- Use bulleted lists for features and requirements
- Use Mermaid diagrams for architecture — never describe architecture in prose when a diagram would be clearer
- Use bold for key terms on first introduction
- Keep paragraphs short — 2-3 sentences maximum
- Use headers to break up sections — a founder should be able to scan and find what they need
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: founder-communication3description: Communication guidelines for non-technical founders. Plain English defaults, analogy-first explanations, progressive disclosure. Use when generating any user-facing architecture output. Use when this capability is needed.4---56# Founder Communication78Guidelines for communicating architecture decisions to non-technical founders and early-stage teams. These rules apply to all outputs unless the user explicitly requests deep technical language.910---1112## Default: Plain English1314- Write as if explaining to a smart person who has never written code15- Use everyday language: "database" not "persistence layer", "background job" not "async worker", "login system" not "identity provider"16- If a technical term is necessary, explain it immediately: "Redis (a fast in-memory cache — think of it as short-term memory for your app)"1718## Acronym Rule1920Expand every acronym on first use in every deliverable:2122- API (Application Programming Interface)23- SSE (Server-Sent Events)24- CDN (Content Delivery Network)25- LLM (Large Language Model)26- MAU (Monthly Active Users)27- CI/CD (Continuous Integration / Continuous Deployment)28- SDK (Software Development Kit)29- JWT (JSON Web Token)30- CRUD (Create, Read, Update, Delete)3132After the first expansion, use the acronym freely.3334## Analogy-First Explanations3536When introducing a concept, use an analogy before the technical definition:3738| Concept | Analogy |39|---------|---------|40| Load balancer | "Like a host at a restaurant — directs customers to available tables" |41| Message queue | "Like a to-do list between two teams — one team adds tasks, the other works through them" |42| Caching | "Like keeping frequently used files on your desk instead of walking to the filing cabinet" |43| WebSocket | "Like a phone call — both sides can talk at any time, unlike email where you send and wait" |44| Vector database | "Like a librarian who understands meaning — finds related documents even if they don't share exact words" |45| API gateway | "Like a reception desk — all visitors check in here before being directed to the right department" |46| Microservices | "Like separate departments in a company — each handles its own job and communicates through email" |47| Container | "Like a shipping container — your app and everything it needs, packed so it runs the same way everywhere" |48| CI/CD pipeline | "Like an assembly line — every code change gets automatically tested and deployed" |4950## Information Order5152Structure every output following this order:53541. **What it does** — business outcome in one sentence552. **Why it matters** — business impact (cost, speed, risk)563. **How it works** — technical explanation (only as deep as needed)574. **What it costs** — dollars and time585. **What could go wrong** — risks in plain language5960Never lead with technical implementation details. A founder reading the output should understand the business value in the first 2 sentences.6162## Risk Communication6364Use these severity levels consistently:6566| Severity | Label | Meaning | Example |67|----------|-------|---------|---------|68| Low | "Manageable" | Standard engineering challenge, well-understood solution | "Real-time updates add some complexity but it's a solved problem" |69| Medium | "Significant" | Requires careful planning or specialized expertise | "Multi-tenant data isolation needs to be designed carefully from day one" |70| High | "Potential dealbreaker" | Could fundamentally change scope, timeline, or feasibility | "HIPAA compliance adds 2-3 months and requires specialized infrastructure" |7172Always pair a risk with a mitigation: "This is significant because X, but you can manage it by Y."7374## Cost Communication7576- Always use ranges, never single numbers: "$50-150/month" not "$100/month"77- Always include what drives the cost up or down: "Closer to $50 if you stay on free tiers, $150 if you need production-grade monitoring"78- Always compare to something relatable: "About the cost of a nice dinner out each month" or "Less than one hour of developer time"79- Break costs into categories a founder cares about: infrastructure, third-party tools, AI/LLM usage, development8081## Progressive Disclosure8283Start simple. Add detail only when:84851. **The user asks** — "Can you go deeper on the database choice?"862. **The user demonstrates technical knowledge** — if they mention specific technologies, frameworks, or patterns, match their level873. **The decision requires it** — some architecture choices genuinely need technical context to understand the tradeoff8889If in doubt, keep it simple. A founder who wants more detail will ask.9091## Formatting Rules9293- Use tables for comparisons (stacks, costs, options)94- Use bulleted lists for features and requirements95- Use Mermaid diagrams for architecture — never describe architecture in prose when a diagram would be clearer96- Use bold for key terms on first introduction97- Keep paragraphs short — 2-3 sentences maximum98- Use headers to break up sections — a founder should be able to scan and find what they need99100---101> Converted and distributed by [TomeVault](https://tomevault.io/claim/navraj007in) — claim your Tome and manage your conversions.102<!-- tomevault:4.0:skill_md:2026-04-14 -->
tomevault-io