When I pick up a new tool, the first thing I count is not the feature list. It is whether I can burn through the free allowance in a single sitting. If I can, I learn within a day whether the tool suits me. If I cannot, my judgment gets spread across a week whether I like it or not.
Last week I was recounting Rork's free allowance and stopped. Thirty-five credits a month. On its own that sounds like enough to assemble one small app. Then I read the daily cap — five — and the premise flipped.
Thirty-five is not a pool you can dip into freely. It is five, seven times over. For anyone trying to evaluate Rork without paying, the constraint is not volume. It is the fact that your work has to cross days.
The numbers, side by side
Let me put the current figures down first. Rork bills by message: every time the AI writes or rewrites code for you, credits come off the balance.
| Plan | Credits | Daily cap | What it realistically covers |
|---|---|---|---|
| Free | 35 / month | 5 / day | Assembling one small app and getting a feel for the tool |
| Pro (from $25/month) | 100 / month | None | Having a day where you push straight through |
| Max | From 1,000, stepping up through 2,500 / 5,000 / 10,000 | None | Ongoing work that reaches into native features |
I should say where those numbers come from. The 35-per-month free allowance with its 5-per-day cap, the $25 Pro tier with 100 credits, and the Max credit steps are all reported consistently across 2026 third-party breakdowns such as Rork Pricing 2026 by No Code MBA and Rork Pricing Plans 2026 by VP0. Billing pages get revised, so please check the figure on your own account screen before you pay anything.
One more thing worth saying plainly: several reviews report that new accounts do not always receive their free credits right away. If your balance shows nothing on day one, you do not need to assume you did something wrong. My own rule is to look once more the next morning, and if nothing has changed, write to support rather than keep poking at it.
Five a day constrains your order of work, not your speed
For a while I treated the free allowance as a small budget — less money, but money I could spend whenever I needed it. That framing did not work well for me.
A daily cap behaves less like a budget and more like a timetable. Once the fifth message is spent, the day is over. Tomorrow's version of you starts by remembering where yesterday left off, and on some days that remembering took longer than the work itself.
So I drew a line I still keep. The free tier is not a tier for building. It is a tier for deciding. I assign each of the five messages to one question I want settled that day, and when it is settled I stop. Writing those questions down in advance is what makes five feel like enough.
In practice my week looks roughly like this. Day one is skeleton: screens and navigation only, so I can see how accurately my wording turns into structure. Day two is data shape — what appears in the list, what appears in the detail view. Day three is input and saving. Day four is visual adjustment. Day five is touching it on a real device and fixing what that reveals. Ordered this way, changing my mind midweek does not throw away the earlier days.
Write the whole spec before you send anything
Most of my credit loss came from round trips, not from feature count. "Build this," "not like that," "try this instead" — every undecided detail turns into another message.
Now I draft the spec in a plain text editor and only then send it. Something like 200 words, along these lines:
# Goal
(Who, in what situation, can do what in a single action)
# Screens
1. List: what is shown, in what order / what appears when empty
2. Detail: fields displayed / fields editable
3. Settings: only the values that can change
# Data
- Field names and types, and whether they live on device or on a server
- What is read at launch / when writes happen
# Out of scope for now
- (Notifications, payments, sharing — anything I do not want generated yet)The line that earned its keep was the last one. Without it, features I never asked for arrive anyway, and removing them costs another message. Stopping one unwanted generation saves a fifth of the day.
If you want to go deeper on how to phrase requests to Rork, building features one increment at a time covers the phrasing side in more detail.
Move verification outside the credit budget
If you also ask the AI to confirm whether the result is correct, every confirmation costs credits. That part can happen on your own machine.
Once the project is exported and sitting in front of you, these two cost nothing:
# Checks dependencies, config, and native-side mismatches in one pass
npx expo-doctor
# Looks only at whether any dependency is off for your SDK version
npx expo install --checkBoth are Expo commands and have nothing to do with your Rork balance, so you can run them as often as you like. Since I settled on paying credits for generation and time for verification, my free allowance has stretched noticeably further. Knowing in advance whether a failure comes from dependencies or from how I phrased the request makes the next message far more precise.
For the order in which I check a build that will not compile, the build failure triage list is worth one pass before you spend anything.
The ceilings you hit before the credits run out, and what free actually verifies
It is easy to talk about credits and miss the fact that two other walls arrive first.
The first is real-device testing. A screen that behaves in the browser preview or the simulator is not the same thing as a build installed on your own phone. I have learned not to call a preview finished, and the gap between preview and a store build walks through what specifically differs.
The second is publishing. Shipping to the App Store requires an Apple Developer Program membership, and Google Play has its own one-time registration fee. Those are separate from the builder's pricing, and they involve human steps that no plan removes. "Can I build this for free" and "can I ship this for free" are genuinely different questions.
Here is the whole thing on one page. Before you start, the only check I would ask you to make is whether you are expecting anything from the right-hand column.
| What the free tier verifies | What it cannot (paid, or a separate cost) |
|---|---|
| How accurately plain-language instructions become screens | How much rework accumulates over sustained building |
| Whether the generated code is readable to you | Finishing something without crossing days |
| A first pass at navigation and data shape | How comfortably you can ship updates after release |
| Whether your idea holds up in two or three screens | Work that reaches into native capabilities (higher tiers) |
My own test for moving to a paid plan is a single question: on day five of the free allowance, did I still want to be working on the same app? If the answer was yes, $25 is inexpensive. If interest had faded by day three, I take that as a signal about the idea rather than the tool.
If you want a closer comparison of which plan fits which situation, an honest look at Rork's pricing tiers works through it case by case.
Decide tomorrow's five tonight
If there is one thing to do today, it is to write down the five questions you want answered tomorrow. Keep them small enough to stop on — "decide the sort order for the list," "decide whether data lives on device" — and your morning self will not spend the first message wandering.
I could not make the free tier work while I thought of it as a trial period. It started working once I thought of it as a place to decide things. Thank you for reading this far, and I hope your five go further than mine did at the start.