> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rocket.new/llms.txt
> Use this file to discover all available pages before exploring further.

# Best practices

> Prompt patterns, iteration strategies, and complexity management techniques for Rocket.new Build.

export const LlmsDirective = () => <blockquote className="llms-directive">
    For the complete documentation index, see <a href="/llms.txt">llms.txt</a>.
    For a lightweight markdown version of this page, append .md to the URL.
  </blockquote>;

<LlmsDirective />

This page is your reference for getting the most out of Build tasks. These patterns consistently produce better results: faster generation, cleaner code, fewer bugs, and apps that match your vision.

## Structuring prompts for complex apps

The quality of your prompt directly determines the quality of the initial generation. A well-structured prompt saves rounds of iteration.

<AccordionGroup>
  <Accordion title="Lead with purpose, not features">
    Start by explaining what the app does and who it is for. This context shapes every decision Rocket makes about architecture, UI patterns, and component choice.

    **Good:**

    ```plaintext wrap theme={null}
    Build a project management tool for small marketing teams. They need to track campaigns, assign tasks to team members, and see progress at a glance.
    ```

    **Less effective:**

    ```plaintext wrap theme={null}
    Build an app with a kanban board, user list, calendar, settings page, and charts.
    ```

    The first prompt gives Rocket context to make intelligent design decisions. The second is just a list of features with no guiding purpose.
  </Accordion>

  <Accordion title="Use the 3-5 feature rule">
    Include three to five key features in your initial prompt. This is the sweet spot - enough detail to generate something useful, not so much that the app becomes unwieldy.

    After the initial build, add complexity through chat one feature at a time. This incremental approach produces cleaner, more reliable results than front-loading every feature.
  </Accordion>

  <Accordion title="Separate design from functionality">
    If you have strong visual preferences, state them separately from the feature list:

    ```plaintext wrap theme={null}
    WHAT TO BUILD:
    A client portal where users can view invoices, download receipts, and manage their subscription.

    HOW IT SHOULD LOOK:
    Clean and professional. White background, navy text, subtle gray borders. Use a sidebar navigation. Inspired by Stripe's dashboard.
    ```

    This separation lets Rocket optimize each dimension independently.
  </Accordion>

  <Accordion title="Name the screens explicitly">
    Instead of relying on Rocket to infer what screens you need, list them:

    ```plaintext wrap theme={null}
    Screens: Dashboard, Project List, Project Detail, Task Board, Team Members, Settings, Profile.
    ```

    This ensures nothing important is missing and gives you control over the initial scope.
  </Accordion>

  <Accordion title="Include example data">
    Providing realistic example data makes the generated app much more useful for evaluation:

    ```plaintext wrap theme={null}
    Example data: Show 3 projects ("Q2 Brand Campaign", "Website Redesign", "Product Launch"). Each has 5-8 tasks with different statuses. Team members are "Sarah K.", "James L.", and "Priya M."
    ```

    Without example data, Rocket uses generic placeholder text that makes it harder to evaluate the design.
  </Accordion>
</AccordionGroup>

## Iteration patterns

Building a great app is an iterative process. These patterns help you iterate efficiently.

<AccordionGroup>
  <Accordion title="Incremental iteration: build one feature at a time">
    After the initial generation, add complexity one feature per message:

    1. "Add user authentication with email/password sign up and sign in"
    2. "Add a settings page where users can update their profile and change their password"
    3. "Connect Supabase and store task data in a tasks table"

    Each step builds on the last, and you can verify each addition before moving on. This is more reliable than asking for everything at once.
  </Accordion>

  <Accordion title="Wholesale iteration: regenerate from a better prompt">
    If the initial generation missed the mark significantly, it is often faster to start a new task with a better prompt than to iterate the existing one into shape. Signs you should start over:

    * The app type or framework is wrong
    * The overall architecture does not match your needs
    * More than half the screens need major changes
    * The visual direction is completely off

    Copy what worked from the first attempt into your improved prompt.
  </Accordion>

  <Accordion title="Visual-first iteration: get the look right, then add logic">
    For apps where design matters (landing pages, consumer apps, portfolios), focus on getting the visual design right before adding functionality:

    1. Generate the initial app
    2. Use Visual edit and chat to perfect the layout, colors, and typography
    3. Then add interactive features, data connections, and business logic

    This prevents logic changes from breaking visual progress.
  </Accordion>

  <Accordion title="Logic-first iteration: build features, then polish design">
    For internal tools, dashboards, and data-heavy apps, the opposite approach works better:

    1. Generate the initial app
    2. Add all features, data connections, and business logic
    3. Then polish the visual design

    This prevents design polish from being wasted when feature changes restructure the layout.
  </Accordion>
</AccordionGroup>

## Managing complexity in large apps

As apps grow, complexity becomes the main obstacle. These strategies keep large projects manageable.

<AccordionGroup>
  <Accordion title="Build in phases">
    Break your app into logical phases and complete each phase before starting the next:

    **Phase 1: Core** - The essential screens and navigation. Your app should be usable (if basic) at the end of this phase.

    **Phase 2: Features** - Authentication, data persistence, connectors. The app becomes feature-complete.

    **Phase 3: Polish** - Responsive design, error handling, loading states, animations. The app becomes professional.

    **Phase 4: Optimization** - Performance, SEO, accessibility. The app becomes production-ready.
  </Accordion>

  <Accordion title="Keep the screen count under control">
    Apps with more than 15-20 screens in a single task can become difficult to manage. If your app is larger:

    * Generate core screens in the initial task
    * Add additional screens through chat one at a time
    * Consider splitting into multiple tasks if sections are independent

    Rocket handles large apps well, but your ability to review and iterate effectively decreases as the screen count grows.
  </Accordion>

  <Accordion title="Use clear naming in your prompts">
    When referring to specific elements during iteration, use precise names:

    * **Good:** "On the Dashboard page, move the revenue chart above the recent activity list"
    * **Too vague:** "Move the chart to the top"

    As your app grows, ambiguous references can cause Rocket to modify the wrong element.
  </Accordion>

  <Accordion title="Test after every significant change">
    Check the preview after each feature addition or layout change. Catching issues immediately is much faster than discovering them later when the cause is unclear. See [Testing strategies](#testing-strategies) below for the full workflow.
  </Accordion>
</AccordionGroup>

## Working with generated code

Understanding the generated code gives you more control over your app.

<AccordionGroup>
  <Accordion title="Use Code for precision edits">
    When chat and Visual edit cannot achieve exactly what you want, open [Code](/build/editor/code) and edit the source directly. This is particularly useful for:

    * Adjusting specific pixel values
    * Adding conditional logic
    * Modifying component props
    * Fixing edge cases that chat cannot describe precisely
  </Accordion>

  <Accordion title="Inject custom code for advanced features">
    [Custom code injection](/build/editor/custom-code) lets you add scripts, styles, and code snippets that Rocket does not generate natively. Use it for third-party widgets, custom analytics, advanced animations, or business logic that requires specific implementation.
  </Accordion>

  <Accordion title="Download for local development">
    If you need capabilities beyond what the Rocket interface offers, such as automated testing, CI/CD pipelines, or custom build steps, download the project as a `.zip` from the Code toolbar (paid plan required) and continue in your preferred IDE.
  </Accordion>

  <Accordion title="Understand the file structure">
    Familiarize yourself with where things live in the generated project. Knowing the structure helps you navigate Code and make targeted edits without guessing which file to open.
  </Accordion>
</AccordionGroup>

## Testing strategies

<AccordionGroup>
  <Accordion title="Test the happy path first">
    Walk through the primary user flow from start to finish. Can a new user sign up, complete the core action, and see the expected result? If the happy path works, the app is functional.
  </Accordion>

  <Accordion title="Test edge cases with empty and extreme data">
    What happens when a list is empty? When a text field has 1,000 characters? When no image is provided? These edge cases reveal missing error handling and broken layouts.
  </Accordion>

  <Accordion title="Test on mobile">
    Resize the preview panel to mobile width (375px) and navigate every page. Mobile breakpoints are where most layout issues appear - overlapping elements, text overflow, unreachable buttons.
  </Accordion>

  <Accordion title="Test with fresh eyes">
    After working on an app for hours, you lose perspective. Share the preview with someone who has not seen it. Fresh eyes catch confusing navigation, unclear copy, and broken flows that you may have become blind to.
  </Accordion>
</AccordionGroup>

## Common patterns and anti-patterns

| Pattern                     | Why it works                                                       |
| :-------------------------- | :----------------------------------------------------------------- |
| Start with a focused prompt | Produces a cleaner initial generation that is easier to iterate on |
| Add features incrementally  | Each addition is isolated and testable                             |
| Test after every change     | Bugs are caught immediately, not compounded                        |
| Reference specific designs  | Anchors the visual direction and reduces ambiguity                 |
| Separate design from logic  | Lets you optimize each dimension without interference              |

| Anti-pattern                              | Why it fails                                                                              |
| :---------------------------------------- | :---------------------------------------------------------------------------------------- |
| Front-loading every feature in one prompt | Produces cluttered, inconsistent results that need more rework                            |
| Making many changes without testing       | Bugs compound and become harder to diagnose                                               |
| Vague prompts ("make it better")          | Produces generic improvements that miss your specific vision                              |
| Ignoring mobile until the end             | Forces major restructuring late in the process                                            |
| Over-iterating instead of shipping        | Once the output looks good, ship it and get real feedback rather than polishing endlessly |

<Divider />

## What's next?

<CardGroup cols={2}>
  <Card title="Build your first app" icon="bolt" href="/build/quick-start">
    Put these practices to work with a guided walkthrough.
  </Card>

  <Card title="Connectors" icon="grid-2" href="/build/connectors/overview">
    Add payments, databases, AI models, email, and more to your app.
  </Card>

  <Card title="Preview your app" icon="eye" href="/build/editor/preview">
    Live preview, responsive testing, and screenshot capture as you build.
  </Card>

  <Card title="Launch your app" icon="desktop" href="/build/launch-web/launch-your-site">
    Publish your app to the web and connect a custom domain.
  </Card>
</CardGroup>