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