Reading recent Rork reviews, alongside the praise for what it can do, I keep seeing one recurring note: credits get consumed faster than people expect. One 2026 review even logged it precisely — roughly 70% of the bugs in a generated app were fixed by the AI itself, while the remaining 30% were patched by hand in the exported code.
When I read that number, my first thought wasn't "no wonder the credits drain." It was that the draining follows a predictable pattern, and with a little discipline of my own, the monthly spend could be much calmer. From years of quietly maintaining several apps as an indie developer, I've learned that a tool you use while anxious about hitting a billing ceiling is a tool you eventually stop reaching for. Getting the workflow to a place where it isn't scary is, to me, the condition for using a tool over the long run.
Why credits "drain before you notice"
The biggest reason credits go fast is not generation itself — it's regeneration. You give a vague instruction, look at the result, feel it's slightly off, rephrase, and it's still a little off. When that round trip happens two or three times for a single screen, you've paid several times the credits you needed to.
Early on, I leaned on the casual comfort of "just have it built, then fix it after I see it." But that approach was simply outsourcing my own unsorted thinking to credits. The part of my idea that wasn't yet clear, I was filling in with the number of times I queried the tool. The fast drain wasn't the tool's fault; it was my lack of preparation.
Separate "credit work" from "by-hand work"
So the first line I drew was deciding what to ask the AI for and what to fix with my own hands. The axis is simple: "is a round trip likely?" and "is it faster to fix by hand?"
| Type of work | How to handle it | Why |
|---|---|---|
| Screen scaffold / first draft | Generate with credits | Faster than from scratch; small harm if slightly off |
| Copy, color, spacing tweaks | Fix by hand | Prone to round trips; generation is heavy for a one-line change |
| Changing a constant or threshold | Fix by hand | Seconds, if you know where it lives |
| Integrating an unfamiliar library | Generate with credits | Collapses the research time into one pass |
| Diagnosing a reproducible bug | Check by hand first | Asking without a hypothesis multiplies round trips |
Take a change as small as wanting 30 items per page instead of 20. Asking for it in words sends the tool off to find the spot, read around it, rewrite, and verify — a whole generation pass. But if you already know where it lives in the exported code, fixing it by hand is dramatically faster and costs no credits.
// Faster to fix this one line in the exported code by hand than to re-ask in words
const PAGE_SIZE = 30; // was 20Keep tossing these "faster by hand" changes at the AI and your credits erode like dust piling up. Conversely, for unfamiliar territory or a from-scratch foundation, spend credits without hesitation. With the line drawn, the spending starts to feel justified.
Go far in a single instruction
The most effective way to cut round trips was to make the first instruction thick. When I decide the finished shape in my head before asking, a single generation gets me surprisingly far. Before asking for a new screen, I jot these four points as a note to myself.
- Goal: what does the user accomplish on this screen (one sentence)
- Input and state: data it receives; the empty, loading, and failed views
- Actions: what taps and swipes do, and where they navigate
- Constraints: match existing colors, spacing, naming; add no new librariesThis note is less for the AI than for settling my own thinking first. Putting the empty and failure states into words up front erases the classic round trip where you later realize "wait, what does loading look like?" and have to re-ask. In my experience, just adding these four points cut the round trips per screen by more than half.
Writing thick makes the instruction longer and feels like a chore, but one long instruction is cheaper — and faster — than three short ones.
Discard failures early, treat credits as a runway
Even so, generations that veer off course are inevitable. What matters here, I've found, is the courage to let go of a result that isn't working and discard it early. Trying to nudge a half-wrong output back into shape, one rephrase at a time, stacks up round trips and ends up costing more than asking again from scratch. If three fixes don't get me closer, I rewrite the instruction itself — that's a rule I've made for myself.
And at the start of each month, I look at that month's available credits as a runway for development. Rather than checking the balance at month's end, I glance at it roughly each week. If it's draining past the halfway mark too quickly, I shift more of that week toward by-hand fixes. It's less about scrambling once the credits are gone, and more about taking off while staying aware of how much runway is left.
| Week | How to read it | Adjustment if draining fast |
|---|---|---|
| Week 1 | Fine to spend heavily laying down new screens | — |
| Week 2 | Check whether more than half remains | Move small tweaks to by-hand |
| Week 3 | Lock the spec before any large generation | Commit to thick instructions, cut round trips |
| Week 4 | Mostly polish and hand-fixes | Push new generation to next month's runway |
Since switching to this view, the accident of running out of credits mid-month and grinding to a halt has nearly disappeared. Once the spending becomes predictable, trust in the tool oddly grows too. A tool that isn't scary is one you naturally reach for more often.
The next step
If your credits feel like they're draining fast right now, try recalling the last three fixes you asked the AI for. How many were ones where you knew the spot and could have fixed it by hand? You'll likely find one or two. Moving that one to by-hand work next time is, I think, the smallest and surest first step toward cost discipline.
Don't fix the price of the tool — fix how you live with it. Shaping a tool into something you can keep using for a long time is the modest conclusion I've reached from years of choosing tools as an indie developer. Thank you for reading to the end.