The first few apps you build in Rork are usually exhilarating — something that runs, on a phone, in minutes. But by your third or fourth app a different feeling sets in: "I don't know what to ask Rork for," "the same prompt produces different apps each time," "I keep redoing the same fix."
After 20+ Rork apps, my conclusion is that those frustrations aren't about Rork. They're about how the human side decomposes requirements. And much of what makes requirement decomposition work is borrowed straight from the math behind search engines and classifiers — exactly the curriculum laid out in books like Jujun Furushima's Self-Taught Mathematical Thinking.
This post lays out a way of thinking about Rork app development that holds up in the AI coding era.
App development is an information-pruning problem
Ask Rork for "an expense tracker app" and you'll get something that runs. Whether it's the expense tracker you wanted is another question.
Mathematically, the label "expense tracker" points to an enormous space of possible implementations. Simple amount entry, receipt OCR, bank account integration, graph-heavy, multi-user — easily 100+ variants. With no further information, Rork picks one (essentially according to the bias of its training data).
A search engine prunes 10 billion pages down to 10. Rork prunes the space of "expense tracker apps" down to one. A good prompt is the act of deliberately narrowing that space.
"Expense tracker app" alone barely prunes. "Personal use, monthly aggregation, three categories — food, transport, entertainment, one pie chart, SQLite local storage" — that aggressively prunes the space, and Rork's output stabilizes accordingly.
Decompose requirements into five layers
Here's the framing I use before every Rork session. It's faceted-search style: split requirements into independent dimensions you can tighten one by one.
Layer 1: User and use scenario. Who, when, where, why. "Me, while waiting for a train, quickly recording the cash in my wallet."
Layer 2: Core functionality. The one to three features without which the app doesn't exist. For an expense tracker maybe just "log a spend" and "view monthly totals."
Layer 3: Data model.
Concrete data shapes. expense(id, amount, category, date, memo).
Layer 4: Rough UI structure. Number of screens (three to five is realistic to start) and what each does. "Tab 1: input, Tab 2: monthly chart, Tab 3: settings."
Layer 5: Technical constraints. What Rork should and shouldn't use. "Local storage only, no auth, must work offline."
Write the five layers before prompting and Rork's first output will be much closer to what you wanted. Conversely, fuzziness in any layer tends to flow straight into instability in the resulting app.
Specify both positives and negatives
In ML, training a classifier on positive examples only produces a model that calls everything positive. Negatives matter just as much.
The same is true in Rork prompts. "Use a simple design" leaves "simple" undefined — Rork might add gradients or shadows. Pin it down: "Simple = white background, no shadows, all text in black, single-color flat buttons" — then add explicit negatives: "Forbidden: gradients, shadows, emoji, any non-circular icons."
Template I use:
## What I want (positives)
- ...
## What I don't want (negatives)
- ...
## What you can decide on your own
- ...
## What you must ask me about
- ...
The fourth section — "must ask me about" — is the strongest safety lever. "Ask before changing the database schema" is enough to keep Rork from rewriting your existing tables on a whim.
Make a habit of asking for confidence
Probabilistic models distinguish between point estimates and full distributions. Same with Rork.
"Add a login feature" returns one implementation. You can't see how confident Rork is in it. Rephrase: "Propose three login implementations with pros and cons. Recommend one and state your confidence (high/medium/low)." Now Rork surfaces its uncertainty.
When confidence is "low," Rork is likely guessing. That's the moment to ask follow-up questions — before code lands. It's the same logic as "request additional observations in regions of high uncertainty," ported into agent collaboration.
Excessive emphasis is counterproductive
In TF-IDF terms, words that appear everywhere in a document carry less signal. Repeating the same word reduces its information weight.
Same in Rork prompts. "Absolutely please…", "definitely…", "this is super important…" — repeated again and again, Rork starts treating these as decoration and tunes them out.
Better: state critical constraints once or twice, marked clearly. [Important] Don't change the database schema. One marker, used sparingly, lands far harder than five repetitions.
Five common mistakes
Putting it all together, here are the five mistakes I see most often:
Mistake 1: Vague qualifiers like "nice" or "well." Zero information content. "Round card corners 8px, soft shadows" instead.
Mistake 2: Asking for the whole app in one prompt. Quality drops on every feature. Build core feature first, then layer the rest one prompt at a time.
Mistake 3: Skipping the data model. Starting from UI and bolting data on later means rebuilding when the model doesn't fit. Data model → screen structure → UI details, in that order.
Mistake 4: Ignoring the existing codebase when asking for changes. "Add another screen" mid-project can produce inconsistencies. "Add the next screen to the existing NavigationStack" pins down the integration point.
Mistake 5: Vague tests. "Write tests" yields shallow tests. "Write E2E tests covering the three core flows: log → aggregate → delete" is concrete enough to be useful.
Closing thought: treat Rork as a high-information collaborator
Treat Rork as "a tool that writes code" and you'll repeat the same failures. Treat it as "a collaborator you progressively narrow context with" and your own requirement understanding deepens — and the apps get better as a side effect.
Mathematical thinking sounds intimidating. The essence is simple: ask "structurally, what kind of problem is this?" Reframe Rork sessions as information-pruning problems and what to communicate, what to verify, becomes obvious.
Suggested next step: take your current app idea and write it through the five-layer decomposition above. The exercise will surface which layer is fuzziest in your own thinking. Tighten that layer first, then prompt — your first Rork prototype will land a noticeable level higher in quality.