Reading Rork's $15M Seed Round as an Indie Developer — What I Checked Before Committing, and What Broke on the Way to Launch

What early users actually get, and what they only hope for

This is where careful separation pays off. The belief that early users get rewarded is, historically, about half right.

As far as I can verify, Rork has announced no lifetime price lock and no permanent early-adopter discount. Making a business decision on the assumption that one will appear, because other companies have done it, is a genuinely risky bet.

That said, the early position does carry real advantages.

Row three is the one I have felt most. Throwing the same task at Rork month after month makes quality improvements obvious in a way that release notes never do. That signal only accumulates for people who started early.

Set the walk-away line with arithmetic, not instinct

The first row of that table said to decide your walk-away price before you need it. That is not a mindset exercise. It is a calculation.

My wallpaper app earns primarily through AdMob interstitials. Assume a roughly ¥300 eCPM for the Japanese market, one impression per session, and 1.5 sessions per DAU per day. Monthly ad revenue from a single daily active user works out to:

1.5 sessions x 30 days x ¥300 / 1,000 = about ¥13.5 (converted at ¥150 per dollar; the plan prices are what I assumed at the time of writing, so please check the official pricing page before subscribing)

From there you simply divide the plan price by that number.

Having this table on hand made decisions noticeably faster. Subscribing to Max for an app that has not cleared 300 DAU means the spend is an investment in learning, not in revenue.

There is nothing wrong with investing in learning. It is simply a different act from running a loss while believing you are monetizing.

My own walk-away line sits at "when the DAU figures in that table effectively double." If credit rules shift and the same work takes twice the round trips, the real cost has doubled even with an unchanged price tag. The first metric in my monthly benchmark feeds straight into that decision.

Doing this by hand gets tiresome every time eCPM or session count changes, so I keep a short script nearby. The figures in the table above come from running it.

import math
 
def break_even_dau(plan_usd, fx=150, ecpm=300, sessions=1.5, days=30):
    """DAU needed to cover a plan's price (rounded up)."""
    revenue_per_dau = sessions * days * ecpm / 1000  # yen per month
    return math.ceil(plan_usd * fx / revenue_per_dau)
 
for name, usd in [("Junior", 25), ("Senior", 100), ("Max", 200)]:
    print(name, break_even_dau(usd))
# Junior 278 / Senior 1112 / Max 2223

If eCPM halves to ¥150, the DAU you need exactly doubles. Ad rates move somewhere I cannot reach, so I draw the walk-away line twice: once at today's numbers, and once at what they would be if the rate were cut in half.

After committing: building a state I can retreat from

My conclusion was to stay on the Expo side while making sure I could leave at any point. Trusting a platform and designing how deeply you depend on it are two separate decisions.

The first thing I built was a snapshot habit. Rork keeps history in its own interface, but if the output never lands in my repository, I cannot answer "what changed since last month" later.

#!/usr/bin/env bash
# rork-snapshot.sh — pull a Rork export into your own repo so every generation is diffable.
# Usage: ./rork-snapshot.sh ~/Downloads/rork-export-2026-04-09.zip "after adding AdMob"
set -euo pipefail
 
ZIP="${1:?pass the path to the exported zip}"
NOTE="${2:-}"
REPO="$HOME/apps/wallpaper-rn"        # the repo you control
STAGE="$REPO/generated"               # generated output lives here and nowhere else
 
[ -d "$REPO/.git" ] || { echo "no repo at: $REPO"; exit 1; }
 
# Replace the generated tree wholesale. Hand-written code lives outside generated/.
rm -rf "$STAGE"
mkdir -p "$STAGE"
unzip -q "$ZIP" -d "$STAGE"
 
# Lockfiles and node_modules drown the diff, so drop them
find "$STAGE" -name node_modules -type d -prune -exec rm -rf {} + 2>/dev/null || true
find "$STAGE" -name "*.log" -delete 2>/dev/null || true
 
cd "$REPO"
STAMP="$(date +%Y-%m-%d-%H%M)"
git add generated
if git diff --cached --quiet; then
  echo "no change in generated output ($STAMP)"
  exit 0
fi
 
# Record how many lines moved, right in the commit message
SUMMARY="$(git diff --cached --shortstat)"
git commit -q -m "gen: ${STAMP} ${NOTE}" -m "${SUMMARY}"
git tag -f "gen-${STAMP}"
echo "recorded: ${SUMMARY}"

The important part is not the script. It is the boundary: nothing hand-written ever goes inside generated/. Once you accept that the generated tree gets replaced in full every time, git diff shows you exactly what the AI rewrote without asking.

Edit a generated screen directly and the opposite happens. The next generation silently discards your fix, and nothing tells you it happened. I lost two weeks to this before the rule stuck.

Three things had to live outside the boundary:

1. AdMob unit IDs and remote config keys — embed these in generated files and your production IDs vanish on the next run
2. Store submission metadata — never generated, yet somehow re-hunted every single release
3. Device screenshots and review copy — the assets with the longest useful life

// src/config/ads.ts — lives outside generated/. The AI never touches this file.
type AdSlot = "wallpaper_detail" | "download_complete";
 
const UNIT_IDS: Record<AdSlot, { ios: string; android: string }> = {
  wallpaper_detail: {
    ios: "ca-app-pub-XXXXXXXXXXXXXXXX/1111111111",
    android: "ca-app-pub-XXXXXXXXXXXXXXXX/2222222222",
  },
  download_complete: {
    ios: "ca-app-pub-XXXXXXXXXXXXXXXX/3333333333",
    android: "ca-app-pub-XXXXXXXXXXXXXXXX/4444444444",
  },
};
 
// Hitting live units from a dev build gets you flagged for invalid traffic.
// Resolve the test/live split at build time, never at runtime.
const TEST_UNIT = {
  // Google's official interstitial demo IDs. Reusing banner demo IDs
  // fails to load because the ad format does not match.
  ios: "ca-app-pub-3940256099942544/4411468910",
  android: "ca-app-pub-3940256099942544/1033173712",
};
 
export function adUnitId(slot: AdSlot, platform: "ios" | "android"): string {
  if (__DEV__) return TEST_UNIT[platform];
  return UNIT_IDS[slot][platform];
}

With the __DEV__ branch centralized here, generated screens only ever call adUnitId("wallpaper_detail", Platform.OS). Regenerate the screen as often as you like; the ad configuration survives untouched.

The revenue side of this setup is covered separately in my AdMob monetization strategy for Rork apps.

Four submission blockers, all of them outside the generated code

Taking the prototype through App Store and Google Play review, every place I got stuck sat outside what Rork generates. If your setup resembles mine, expect these to recur.

Permission strings go in app.json and get baked in at build time.

{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSPhotoLibraryAddUsageDescription": "Used to save the wallpaper you picked into your Photos library.",
        "NSUserTrackingUsageDescription": "Used to keep ad frequency reasonable. Every feature remains available if you decline."
      }
    },
    "android": {
      "permissions": ["POST_NOTIFICATIONS"]
    }
  }
}

After one rejection over ATT wording, I now spell out that declining costs the user nothing. Leave that ambiguous and the reviewer cannot confirm whether features are gated, which turns into a multi-day round trip of questions.

Privacy manifests get harder as the dependency tree grows. The audit routine I settled on is written up in auditing the Rork SDK chain for privacy manifests.

What all four share: none of them had anything to do with the quality of the generated code. Even when an AI writes the app, getting through review is still human preparation. Miss that and you will wrongly conclude that Rork's output is what got you rejected.

Measuring the post-funding change yourself

You cannot judge whether a platform improved by reading its announcements. So once a month, I run the same task and write down the result.

Three prompts, identical wording every time:

1. Generate a minimal app with a list screen, a detail screen, and a save action
2. Add a filter that shows only saved items, as a follow-up instruction
3. Export the result and check whether it builds without edits

Four numbers get recorded.

The fourth one carries the most weight. The practical value of a generation tool is not the first impressive output; it is whether earlier work survives when you stack instructions on top of it. Tools that fail here feel wonderful during prototyping and fall apart the moment you start operating.

Three months of this and the numbers start making the decision for you. That is a much calmer place to stand than deciding by vibes.

So did I commit

I stayed on Expo. Not because of the size of the round, but because my own monthly numbers showed follow-up prompts doing less damage than they used to.

The funding news was a prompt to re-examine the decision. It was never the evidence behind it. The evidence was four numbers I had been collecting myself.

If you are standing in the same spot, the first move I would recommend is picking your three benchmark prompts. Whether you commit or walk away, by next month you will be deciding with your own data rather than someone else's press release.

I am still feeling my way through much of this, and next month's numbers may well contradict today's read. But with a record in hand, at least I will notice. Thank you for reading.

(I cross-checked the funding facts against several reports. The Paperline acquisition rests on press coverage, and neither the use of funds nor an exact Developer Tools rank is confirmed by an official source.)