Ask AI
Skip to main content

Rocket mode

Rocket Mode – Step‑by‑Step Guide for Citizen Developers​

IMPORTANT NOTICE
Rocket Mode is currently intended for creating new applications. If you’re inside an existing application, first click “Add application” at the top left of your Applications page—this opens Rocket Mode.
NoCode‑X is evolving to support adoption inside existing apps as well; for now, let’s nail the basics. Here we go!

Rocket Mode is your vibe coding assistant. It translates your business idea into a secure, working app foundation—covering design, data, logic, and security—so you can build faster and thrive later in the Visual Development Layer. Some steps may take a moment while the AI “thinks.” Loop protection helps prevent wasted credits. If something feels off, prompt an adjustment and re‑run the step.
Feedback welcome: [email protected]

Index​

Step 1: Application description​

  • Review the proposed app name and one‑line tagline.
  • Adjust the feature list so it matches your goal and audience.

How‑to​

  • Name: Pick something clear and on‑brand. Rename if needed.
  • Tagline: One sentence that says who it’s for and what it does.
  • Features: Write as actions (verbs), not vague labels.
    Example: “Notifications” → “Send email reminders for bookings.”
  • MVP focus: Mark essentials as Must‑have; move extras to Later.

Try these prompts​

  • Rename the app to “[New Name]” and make the tone friendly and trustworthy.
  • Keep only booking, listing, and email reminders as Must; move analytics to Later.
  • Replace “advanced reporting” with “simple attendance export” for MVP.

Checklist​

  • Name fits brand and purpose
  • Clear one‑line tagline
  • Features aligned to your elevator pitch and scoped for MVP

Interface tips​

  • Clear name = clear direction.
  • Features as actions, not jargon.
  • Less is faster and safer.
  • Tie each feature to a real user goal.

Step 2: Customer journey​

  • Map “trigger → steps → success” for each persona (e.g., Guest, Organizer, Admin).
  • Include recovery paths for “no results” and errors.

How‑to​

  • For each persona, write a short story: “As a Guest, I browse → select → book → get confirmation.”
  • Mobile‑first: fewer steps, big buttons, easy back/forward navigation.
  • Empty/error states: “No events found” guidance; “Payment failed—try again or contact support.”
  • Trust cues: progress indicators (1/3 → 2/3 → 3/3), confirmations, helpful microcopy.

Try these prompts​

  • Add a “browse without login” path for first‑time Guests.
  • Show a three‑step progress indicator during booking.
  • Provide an empty state that suggests filters or popular events.

Checklist​

  • Start‑to‑success path for each persona
  • Empty and error states defined
  • Mobile and accessibility considered

Interface tips​

  • Story first: trigger → success.
  • Design detours (errors/empty).
  • Mobile‑first = happier users.
  • Show progress to reduce drop‑offs.

Step 3: Requirements and key features​

  • Prioritize with Must/Should/Could (MoSCoW).
  • Add non‑functional requirements: security, performance, accessibility.

How‑to​

  • Must: essential now; Should: desirable soon; Could: later.
  • Security: authentication, roles, least‑privilege access.
  • Accessibility: aim for WCAG AA contrast and keyboard navigation.
  • Performance: “Lists feel instant; forms save reliably.”
  • Privacy: minimize personal data; set retention policies.

Try these prompts​

  • Promote payment to Must; make social sign‑in a Should.
  • Add accessibility target WCAG AA and visible focus rings.
  • Define roles: Guest (browse), Organizer (create/manage), Admin (moderate).

Checklist​

  • MoSCoW list agreed (Must/Should/Could)
  • Security and accessibility explicit
  • Performance expectations set

Interface tips​

  • Prioritize ruthlessly.
  • Security first by default.
  • Accessibility prevents rework.
  • Define simple acceptance criteria per Must.

Step 4: Design system​

Short version​

  • Choose your palette and fonts; define sizes and states.
  • Use tokens so one change updates everywhere.

How‑to​

  • Tokens to define:
    • Colors: bg, surface, primary, accent, text, muted
    • Spacing scale: 8, 16, 24, 32
    • Radii: small, medium, large
    • Shadows: small, medium
    • Typography: base font, heading sizes (e.g., H1–H4)
  • Components: buttons, inputs, cards, alerts—each with hover/focus/error/disabled.
  • Contrast: body text contrast at least 4.5:1; strong visible focus outlines.
  • Touch comfort: minimum 44×44 px targets.
  • Consistency: the same tokens across all pages for instant coherence.

Example tokens​

  • color-bg: #0f172a
  • color-surface: #111827
  • color-primary: #16a34a
  • color-accent: #06b6d4
  • color-text: #e5e7eb
  • color-muted: #9ca3af
  • spacing: 8 / 16 / 24 / 32
  • radius: 8 / 12 / 16
  • shadow-sm: subtle; shadow-md: deeper
  • font-sans: system UI sans (e.g., Segoe UI, Roboto)

Try these prompts​

  • Shift to a calm palette (navy/slate/mint) and increase button size.
  • Add strong focus rings and higher contrast for small text.
  • Standardize card spacing using an 8px grid.

Checklist (Definition of Done)​

  • Tokens set (colors, spacing, typography)
  • Core components and states defined
  • Contrast and focus verified

Interface tips​

  • Tokens = instant consistency.
  • Contrast and focus = usable and safe.
  • Big targets = fewer mis‑taps.
  • Reserve colors for meaning (error, success).

Step 5: Pages​

  • One page = one job with a single primary action.
  • Add pages instead of cramming multiple jobs into one.

How‑to​

  • List pages with purpose and main call‑to‑action (CTA).
  • Plan states: loading, empty, error for each page.
  • Use breadcrumbs for deeper paths; keep navigation clear and consistent.
  • Consider onboarding pages (“How it works,” “Getting started”) if helpful.

Try these prompts​

  • Split “Manage Events” into “Create Event” and “Event Dashboard.”
  • Add “Profile” with notifications and privacy settings.
  • Add “Help/FAQ” with quick links to common tasks.

Checklist​

  • Each page has a clear purpose + primary CTA
  • Navigation between pages is obvious
  • Loading/empty/error states planned

Interface tips​

  • One job per page.
  • Add pages, don’t overload.
  • States teach and reassure.
  • Repeat the primary CTA near the end.

Step 6: Test users​

  • Create safe test accounts or reuse existing ones.
  • Existing workspace test users show password as “hidden.”
  • New users created by Rocket Mode display their passwords here.
  • You can reset passwords at any time.

How‑to​

  • Check the test user list:
    • Existing users in your workspace appear with password set to “hidden.”
    • New users created by Rocket Mode display passwords so you can log in for testing.
  • Reuse or create more test users to cover different roles (Guest, Organizer, Admin).
  • Reset a test user’s password whenever needed.
  • Keep test users separate from real people; never reuse production credentials.
  • If provided, sign in with a sample test user like [email protected].

Try these prompts​

  • Create three test users: Guest, Organizer, Admin; generate secure passwords.
  • Reset the Organizer test user’s password and show it.
  • Add a temporary “Reviewer” role test user.

Checklist​

  • At least one test user per key role
  • Access confirmed (login works)
  • Passwords stored safely (not in public notes)

Interface tips​

  • Reuse if present; create if missing.
  • “Hidden” means existing; new shows password.
  • Reset any time—keep it safe.
  • Never test with real customer accounts.

Step 7: Database​

  • Define tables, fields, relationships, and who can do what.
  • Minimize personal data and set retention rules.

How‑to​

  • Start from journeys → list entities (Users, Events, Bookings, etc.).
  • Fields: mark required vs optional; add validation (email, date ranges).
  • Relationships: one‑to‑many or many‑to‑many (use join tables like Attendance).
  • Security: role‑based access—who can read/create/update/delete?
  • Privacy: minimize PII; set retention/deletion policies.

Try these prompts​

  • Add Attendance as a join table between Users and Events (user_id, event_id, status).
  • Make phone_number optional; email is the primary contact.
  • Index event_date and location for faster search.

Checklist​

  • Tables map directly to features and journeys
  • Keys/relations and validations defined
  • Access rules + minimal PII documented

Interface tips​

  • Model features, not guesses.
  • Less PII → lower risk.
  • Access rules early = safer app.
  • Add created_at and updated_at to all tables.

Step 8: Test data​

  • Generate realistic sample data to validate flows.
  • Always use synthetic data; never production data in non‑prod.

How‑to​

  • Volume: enough items to test lists, filters, and pagination.
  • Variety: mix past/future dates, full/empty capacities, and common edge cases.
  • Label/tag test data to enable easy cleanup.
  • Run journeys with test data to confirm the app feels right.

Try these prompts​

  • Create 50 test users and 20 events for the next 60 days; include 10 full‑capacity events.
  • Add 5 past events and a few with invalid emails to test validation.
  • Seed data deterministically so results are reproducible.

Checklist​

  • Data exists for all key tables
  • Normal + edge + error cases covered
  • No production data used

Interface tips​

  • Test data = fast validation.
  • Cover edges now, avoid bugs later.
  • Tag for cleanup.
  • Keep a small and a large dataset for performance checks.

Step 9: Root page​

  • Build the home page visual first (headline + primary CTA), then add logic (auth, profile, navigation).
  • This page sets your app’s look, feel, and first‑impression flow.

How‑to​

  • Visual:
    • Hero: one clear value statement and a single primary CTA.
    • “How it works”: three short steps to guide new users.
    • Use tokens for consistent colors, spacing, and typography.
    • Navigation: simple, with a clear “current page” indicator.
  • Logic:
    • Authentication: sign in/up (if needed), password recovery, session handling.
    • Profile menu: Settings, Privacy, Sign out.
    • Navigation: link to key pages; protect routes requiring login.
    • Optional telemetry: track clicks and drop‑offs to improve UX.

Try these prompts​

  • Make “Browse Events” the primary CTA and add a three‑step “How it works.”
  • Require login for booking; allow browsing without login. Add a profile dropdown.
  • Show a friendly 404 and link back to Home.

Checklist​

  • Clear headline and single primary CTA
  • Visual consistency with tokens
  • Auth + profile + navigation working with test users

Interface tips​

  • Home frames everything.
  • Visual, then logic.
  • Test flows with test users.
  • Keep the hero uncluttered.

Step 10: All the other pages one by one​

  • Repeat the pattern: design (visual) → logic (functional) for each page.
  • Always include loading, empty, and error states.

How‑to​

  • For each page:
    • Visual: apply tokens; keep one primary action; add clear guidance text.
    • Logic: wire data, validations, permissions; ensure back/forward navigation.
    • States: loading skeletons/spinners, empty guidance, friendly errors.
    • Performance: paginate big lists; lazy‑load heavy content (images).
    • Consistency: reuse components and patterns from the root page.

Try these prompts​

  • On Event List, add pagination (10 per page) and a search bar.
  • On Event Details, show a gallery, related events, and visible capacity counters.
  • Add inline validation and helpful error messages to the Create Event form.

Checklist (Definition of Done)​

  • Each page has a clear job + primary CTA
  • Data/permissions wired and tested
  • Loading/empty/error states implemented consistently

Interface tips​

  • Copy the root pattern.
  • Teach with states.
  • Paginate for speed.
  • Use breadcrumbs and back links.

Final Notes & Expectations​

  • Iteration is normal: propose → review → adjust → approve.
  • Some steps take a minute; loop protection prevents wasted credits.
  • Keep prompts specific (“Adjust X to Y”) for faster, better results.
  • Never paste secrets or real personal data into prompts.
  • When the steps are done, you’ll be ready to switch to the Visual Development Layer for hands‑on tweaking—with a secure, coherent foundation already in place.

Questions or ideas to improve Rocket Mode? Email [email protected]