Skip to main content

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.

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.
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:
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:
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.
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.
If you have strong visual preferences, state them separately from the feature list:
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.
Instead of relying on Rocket to infer what screens you need, list them:
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.
Providing realistic example data makes the generated app much more useful for evaluation:
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.

​
Iteration patterns

Building a great app is an iterative process. These patterns help you iterate efficiently.
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.
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.
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.
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.

​
Managing complexity in large apps

As apps grow, complexity becomes the main obstacle. These strategies keep large projects manageable.
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.
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.
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.
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 below for the full workflow.

​
Working with generated code

Understanding the generated code gives you more control over your app.
When chat and Visual edit cannot achieve exactly what you want, open 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
Custom code injection 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.
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.
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.

​
Testing strategies

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.
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.
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.
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.

​
Common patterns and anti-patterns

PatternWhy it works
Start with a focused promptProduces a cleaner initial generation that is easier to iterate on
Add features incrementallyEach addition is isolated and testable
Test after every changeBugs are caught immediately, not compounded
Reference specific designsAnchors the visual direction and reduces ambiguity
Separate design from logicLets you optimize each dimension without interference
Anti-patternWhy it fails
Front-loading every feature in one promptProduces cluttered, inconsistent results that need more rework
Making many changes without testingBugs compound and become harder to diagnose
Vague prompts (“make it better”)Produces generic improvements that miss your specific vision
Ignoring mobile until the endForces major restructuring late in the process
Over-iterating instead of shippingOnce the output looks good, ship it and get real feedback rather than polishing endlessly

​
What’s next?

Build your first app

Put these practices to work with a guided walkthrough.

Connectors

Add payments, databases, AI models, email, and more to your app.

Preview your app

Live preview, responsive testing, and screenshot capture as you build.

Launch your app

Publish your app to the web and connect a custom domain.