Best practices

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

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.

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:

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.

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.

Separate design from functionality

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.

Name the screens explicitly

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.

Include example data

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.

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.

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.

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.

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.

Managing complexity in large apps

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

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

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.

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.

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.

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 for a complete testing workflow.

Working with generated code

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

Use Code for precision edits

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

Inject custom code for advanced features

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.

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 and continue in your preferred IDE.

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.

Testing strategies

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.

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.

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.

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.

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	Diminishing returns set in after 5-6 rounds - ship and get real feedback

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.

Testing

Browser testing, preview testing, and pre-deploy checklists.

Launch your app

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