> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getvirtualbrain.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Dos, Don'ts and Pre-Launch Checklist
> The fundamentals of reliable App design on one page, plus a ten-point checklist to run before shipping any App
Everything in the Academy comes down to a handful of habits. This page is the standing reference you return to before every launch: first the dos and don'ts, then the pre-launch checklist.
## Dos and don'ts
| DO | DON'T |
| --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| Start with the fewest blocks that produce a quality output; add only when merging degrades quality. | Build a 12-block App because the process has 12 steps on paper. Merge what the Mainframe can do in one pass. |
| Give every block exactly one objective. | Chain objectives with "and then..." inside one prompt. |
| Open every prompt with a specific expert role. | Start prompts with "Please help me..." or no role at all. |
| Route long content as Knowledge Source and tell the prompt what to retrieve. | Inject entire documents inline, or attach a KS with a prompt that gives the search nothing to aim at. |
| Name variables deterministically: `/job_description` everywhere. | Use synonyms or abbreviations that differ between input, prompt, and documentation. |
| List inline variables in a clearly labeled section at the end of the prompt to separate data from instructions. | Paste long text directly into prose instructions and hope the Mainframe keeps them apart. |
| Refer to upstream content ("the extracted requirements"). | Refer to upstream blocks ("the output of Block 2"): block numbers do not exist at runtime. |
| Specify exact headers, columns, and section lengths in the Output format. | Leave the format open and accept a different layout on every run. |
| Keep prompts under 200 words; let the data be long instead. | Write 600-word prompts full of reminders and repetitions. |
| Use Hidden blocks for intermediate reasoning and summaries. | Show the user raw intermediate outputs that have no standalone value. |
| Use IF/THEN conditions to skip blocks that are not needed for a given run. | Run every block on every job regardless of relevance. |
| Use Multiple Choice for anything that branches (depth, language, report type). | Parse branching decisions out of free text. |
## Pre-launch checklist
Before shipping any App, verify:
1. Every Free Text and Multiple Choice input appears as `/variable_name` under "Inputs:" in at least one prompt.
2. Every Document Upload and Brain is attached as a Knowledge Source on the right block(s), and never listed as a variable.
3. Every block that searches a KS or the web has explicit search context in its prompt (inline variable or descriptive guidance).
4. Upstream outputs routed as KS are actually attached as KS on the consuming block.
5. Variable names are identical across inputs, prompts, and documentation.
6. No prompt references another block by name or number.
7. Each block has one objective; each prompt is under 200 words (max 400).
8. Every Hidden block's output is consumed downstream.
9. Output formats specify exact headers, table columns, and section bounds: run the App twice and compare layouts.
10. No block is overloaded: keep single inline outputs short, and handle heavy consolidations with KS routing, a summarization block, or a split.
**Run the checklist before every launch, not just the first one.** Apps drift as prompts and Brains change around them.
## Related
The no-code builder where you assemble and ship your first App.
Back to the full course and the order to read it in.