Articles/Getting Started

◈ Getting Started/2026-06-19Intermediate

How to Write Prompts for Rork — Tips for Creating Apps Exactly As You Envision

Practical techniques for writing Rork prompts: specifying UI design, describing features, and requesting revisions so the app you get matches the app you imagined.

Rork⁵¹⁵ Prompts² Writing Tips Tips² App Design² UI¹⁰ Instructions

✦ Premium Article

Building apps on my own, I noticed something odd about Rork: the same kind of request would return a screen close to what I pictured one day, and something strangely ordinary the next. While building a medication-tracker screen, I once asked for the exact same feature twice and got two different results, and for a while I couldn't see why.

The answer turned out to be simple. Rork fills the gaps in your instructions with its own judgment. The more gaps you leave, the more generic and safe the result becomes.

The flip side is encouraging: learn to write in a way that closes those gaps, and the output gets remarkably consistent. What follows is how I actually assemble prompts in my day-to-day indie development, with concrete examples and the mistakes that taught me each lesson.

The Basic Prompt Structure

Good prompts have structure.

Template:

# Overall App Concept
[Concise description]

## Feature Requirements
- [Feature 1]
- [Feature 2]
- [Feature 3]

## Design
- [UI Style]
- [Color Scheme]
- [Layout]

## Technical Requirements
- [Technology]
- [Special Needs]

## Detailed Instructions
[Critical specifics]

Let's see real examples.

Example 1: Budget Management App

Weak Prompt

Build a budget management app.

Problems:

No visual direction
Features aren't defined
Rork makes a generic budget app

Strong Prompt

# Budget Management App "My Budget"

Simple, intuitive budget app for daily expense tracking and monthly budgeting.

## Main Features
- Record expenses (amount, category, date, notes)
- Display category totals
- Monthly expense graphs
- Budget goals with overspend warnings

## Screen Layouts

### Home Screen
- Current month total (large display)
- Budget vs actual (progress bar)
- Recent 5 expenses

### Expense Entry Screen
- Amount input
- Category selection (Food, Transport, Entertainment, Other)
- Date picker
- Notes field
- Save button

### Analysis Screen
- Pie chart (spending by category)
- Bar chart (monthly trends)
- Category breakdown details

## Design Requirements
- Color scheme: Blue and white with green accents
- Clean, readable typography
- Rounded buttons, easy to tap
- Intuitive layout

## Critical Details
- Users log expenses frequently, so 3 taps to complete
- Warn clearly when over budget (bright red)
- Mobile-first design

Strengths:

Screen layouts are clear
Each screen's elements are specific
Design tone is explicit
User behavior is considered

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦A mental model for Rork's output variance—four questions (state, order, result, edges) to close gaps before you prompt

✦The 'one concern per instruction' scoping habit, and how to fence off what Rork must not touch

✦A voice-input workflow (Typeless) with a personal dictionary to cut the time spent writing long prompts

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Example 2: Quick Notes App with Social Sharing

Weak Prompt

Build a note app. Add social sharing.

Strong Prompt

# Quick Note App "Quick Notes"

Capture ideas instantly and share them with friends via social media.

## Main Features
- Create/edit/delete text notes
- Auto-save notes
- Share to Twitter / LINE / Facebook
- Color-code notes by priority
- Search notes

## Main Screen
- Top: Large "New Note" button
- Center: Note cards in 3-column grid
- Each card shows:
  - Note preview (first 100 characters)
  - Priority color bar (red=high, yellow=medium, green=low)
  - Creation date
  - Share, edit, delete buttons

## Note Edit Screen
- Top: Title input field
- Center: Large, scrollable text area
- Bottom:
  - Priority dropdown
  - Save button
  - Cancel button

## Share Feature
- "Share" button on each note
- Choose: Twitter / LINE / Facebook
- Auto-generate text + app link
- Allow editing before sending

## Design
- Minimalist, white background
- Accent: Orange
- Modern, readable typography
- Hover states fade buttons slightly
- Responsive design

## Critical Details
- Auto-save as user types (no manual save)
- Share is 1-click (simple)
- Search responds in real-time while typing

How to Write Revision Requests

When an app doesn't match your vision, revision requests matter.

Weak Revision Request

Make it look cooler

Problem:

"Cooler" means different things to different people
Rork doesn't know what to change

Strong Revision Request

Please make these changes:

1. Button Colors
   - Current: Blue
   - Desired: Deep orange (#FF6B35)
   - Reason: Warmer, more inviting feel

2. Note Card Layout
   - Current: 3-column grid
   - Desired: 2-column cards (mobile: 1 column)
   - Reason: More spacious, easier to read

3. Search Bar
   - Current: Small, top-right
   - Desired: Large, prominently at top
   - Reason: Search is a key feature

4. Note Deletion
   - Current: Delete instantly
   - Desired: Show "Are you sure?" confirmation
   - Reason: Prevent accidental deletion

Strengths:

Current state and desired state are clear
Specific hex colors
Reasoning provided
Concrete elements referenced

UI/UX Specification Techniques

Color Specification

Weak:

Make it blue

Strong:

Color Scheme:
- Primary: #0066CC (deep blue)
- Secondary: #E8F4F8 (pale blue)
- Accent: #FF6B35 (orange)
- Text: #333333 (dark gray)
- Background: #FFFFFF (white)

Usage:
- Buttons: Primary color
- Hover: Darker primary
- Warnings: #FF4444 (red)

Layout Specification

Weak:

Make it more organized

Strong:

Layout:
- Header: Fixed, 60px height
- Main: Full width below header
- Footer: Fixed to bottom

Content arrangement:
- Title and search: In header
- Content: Main area
- Navigation: Footer

Spacing:
- Between elements: 16px
- Page edges: 20px

Typography Specification

Weak:

Use readable fonts

Strong:

Typography:
- Headlines: Bold, 24px, line height 1.2
- Body: Regular, 16px, line height 1.5
- Buttons: Bold, 14px

Font families:
- Headlines: Montserrat (modern)
- Body: Open Sans (readable)

Feature Specification Techniques

Weak Feature Request

Add sharing capability

Strong Feature Request

Note Sharing Feature:

1. How to Share
   - "Share" button on each note
   - Choose destination: Email / LINE / Twitter

2. What Gets Shared
   - Full note text
   - Note title
   - "Created with [app name]" signature + link

3. User Experience
   - One click opens share dialog
   - Text can be edited before sharing
   - Cancel button returns to app

4. Limitations
   - Notes over 1000 characters share preview only

Iterative Development Approach

Rather than specifying everything upfront, build in phases.

Phase 1: Core Functionality

Prompt:

Build MVP of a notes app.

Features:
- Create new notes
- Display notes
- Edit notes
- Delete notes

Keep UI minimal. Prioritize working functionality.

Phase 2: UI Polish

Prompt:

Core features work. Now improve the design.

Specifications:
- Modern, blue and white aesthetic
- Simple grid layout
- Large, easy-to-tap buttons

Update these screens:
- Main screen
- Edit screen

Phase 3: Advanced Features

Prompt:

Design complete. Now add these features:
- Note search
- Priority color-coding
- Social sharing

This phased approach ensures quality at each stage.

Common Mistakes & Solutions

Mistake 1: Too-Vague Instructions

"Make it nice" / "Make it cooler"

Solution: Use specific numbers. Hex codes. Pixel sizes.

Mistake 2: Feature Overload

Request 100 features at once

Solution: Phase them. Basic → UI → Advanced.

Mistake 3: Revision Requests Too Brief

"Make the button red"

Solution: Add color code: "Change to #FF0000"

Mistake 4: Negative Phrasing

"Don't make buttons big"

Solution: Use positive language: "Make buttons medium-sized"

Real-World Revision Flow Example

Initial Prompt:

Build a budget app.
Track expenses, show graphs, organize by category.

First Result: Basic app works, but design feels generic.

Revision 1:

Improve the home screen "This Month's Total":

1. Current: Small text
   Desired: Fill 40% of screen
   Font size: 48px
   Background: Gradient (#0066CC → #00D4FF)

2. Add category icons
   - Food: 🍔
   - Transport: 🚗
   - Entertainment: 🎬
   - Other: 📦

Revision 2:

Improve navigation:

1. Fixed tab bar at bottom
   - Home
   - Analysis
   - Add Expense
   - Settings

2. Highlight current page

Revision 3:

On the "Add Expense" screen:

Show frequently-used categories at top for quick access.

Implementation:
- Top: Show user's top 3 most-used categories
- Below: Full category list
- Allow quick-tap entry

This iterative approach produces increasingly refined apps.

Speeding Up Prompt Writing — The Voice Input Option

If you've read this far, you may have noticed something: good prompts tend to be long.

Once you start specifying screen layouts and design requirements properly, a single instruction can easily run several hundred words. As an indie developer writing specs for an audience of one, I often found myself with a complete picture of the app in my head, only to stall at the typing stage.

My workaround is drafting prompts with Typeless, an AI-powered voice input app.

What You Say Becomes a Usable Instruction

Typeless does more than transcribe. It strips out filler words ("um," "you know," "like") and inserts punctuation, producing text that reads like something you typed deliberately.

What you say:
"So, um, when users search for products, I want them to be able to, like, filter by category too, not just keywords"

What you get:
"When users search for products, allow filtering by category in addition to keywords"

The output is clean enough to paste straight into Rork.

Register Your Dev Vocabulary in the Personal Dictionary

Tool names like Rork, Figma, and Supabase — along with your project's feature names — are easy targets for transcription errors. Typeless includes a personal dictionary, and registering frequently used terms noticeably improves accuracy.

Whenever I start a new project, I register the screen names and core feature names first. That alone removed most of my correction work.

When to Speak, When to Type

That said, voice isn't the answer for everything. Here's the split that works for me.

Voice works well for:

Overall app concepts and feature requirements — anything explained in sentences
Behavior descriptions like "what happens when the share button is tapped"
Capturing revision ideas that come to you on a walk

Keyboard works better for:

Precise values like color codes (#0066CC) and font sizes (48px)
The heading structure of the template itself
Instructions containing code snippets

In practice, I prepare the template "frame" from this guide with the keyboard, then fill in each section by voice and fix the numbers by hand afterward. Since adopting this flow, my prompt-writing time has roughly halved.

Typeless is free to start on both iOS and Android. If long prompts have been the part of Rork you dread, it's worth a try.

Why the Same Prompt Produces Different Results

The first thing that throws people about Rork is the variance.

Ask for the same feature twice and you might get a thoughtful screen one day and a forgettable one the next. This isn't Rork being moody. It reflects how much room your prompt left for Rork to decide on its own.

Say only "make a list screen," and Rork quietly answers questions like these for you:

What information does each row show?
Is the order newest-first, or alphabetical?
What appears when the list is empty?
Does it paginate once there are many items?

The more of these you leave blank, the more the result drifts toward a generic, average-looking app. What I learned the hard way as an indie developer is that prompt skill isn't about vocabulary—it's about how deliberately you close these gaps.

Four Questions That Surface the Gaps

Before sending an instruction, I ask myself four things:

State: How does the screen look with zero, one, and many items?
Order: What is the sort key?
Result of an action: After a button is tapped, how does the screen change?
Edges: What happens when input is too long, or a request fails?

Adding a single sentence for each of these stabilizes the output far more than piling on adjectives.

Scope It Down — Change One Concern Per Instruction

I've argued that long prompts are good, but that doesn't mean changing many things at once. The opposite, really.

When a single instruction reaches across a wide area, Rork sometimes rebuilds parts you were already happy with. If you've ever fixed a color only to find the layout changed too, you know the feeling.

So I keep each instruction focused on a single concern.

✅ "Change only the home screen color scheme"
✅ "Add only validation to the signup form"
❌ "Redo the colors, layout, and a new feature together"

And I explicitly protect what I don't want touched.

Change only the home screen color scheme this time.
Do not touch the layout, component structure, or existing features.

Changes:
- Main color from #0066CC to #1B7F5C
- Keep button text white

Writing out "what not to touch" feels redundant, but its presence or absence dramatically changes how often Rork rewrites things you never asked it to.

While building a plant-watering tracker, switching to this "one concern per instruction" habit roughly halved the number of revisions it took to land on a screen I was happy with.

Final Advice

Writing prompts for Rork is an art.

It's not just what you say — it's how you say it.

Don't aim for perfection the first time.

Use this cycle: create → review → revise → refine.

Through this cycle, you'll develop "prompt intuition." Your apps will get closer to your vision with each iteration.

Give it a try. Your app awaits.

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.