Once your first app is finally sitting in the store, a strange thing happens: you want to build a second one. The workflow has settled into your hands, and the rhythm of talking to Rork feels natural now. And for many people, the very first idea is "let me just clone the first app and swap out the insides."
I've leaned on that clone-it-whole move more than once while running several wallpaper apps, and it has helped me as often as it has tripped me up. The speed is real. But so are the side effects that show up later. What you reuse, and what you rebuild from scratch, is worth deciding early. It makes maintaining your second and third apps far lighter.
Why "copy everything" gets heavy six months later
Cloning itself isn't the problem. The trouble starts when you copy the very center of the app along with everything else.
Say you carry over exactly how the first app stores its data — the save mechanism, the shape of each field — into the second one. On the surface they look like different apps, but underneath they're twins sharing the same skeleton. The awkward part is that the two slowly grow apart. A fix you rushed into app one never makes it to app two. A bug you patched in app two sits untouched in app one. Little by little, the places where they're "supposed to be the same but aren't quite" pile up.
You hit the same bug twice and fix it twice. That quietly eats the time the clone was supposed to save you. The reuse decision reads differently when you ask not "is this faster right now?" but "can I comfortably maintain both of these at once, half a year from now?"
What you can reuse without hesitation — the scaffolding
On the other hand, some parts are worth reusing eagerly: the scaffolding around the app, the pieces whose shape barely changes no matter what the app actually does.
Concretely, that means the onboarding screens right after launch, the frame of your settings screen, the theme (the base colors and fonts), the groundwork for billing, and the way you send analytics events. These carry little of any given app's personality; they behave roughly the same everywhere. When I was adding wallpaper apps, the first thing I unified was onboarding. There was almost no reason to rebuild it per app, and keeping it aligned actually helped when I compared first-day retention across them. I wrote up how that went in "Unifying Onboarding Across Six Wallpaper Apps: What One Month of First-Day Retention Showed."
The trick when reusing scaffolding is to ask Rork for it by behavior — "build the onboarding flow the same way as my first app" — rather than hand-porting files. Describing the behavior in words tends to produce code that fits the second app's context better than a manual transplant would.
What you should rebuild — the core
The opposite holds for the part that makes the app that app: rebuild it rather than copy it.
The main screen, the structure of the data you handle, and the words the app uses internally (the names specific to it — "wallpaper," "diary," "task"). Drag these over from app one and your second app's design ends up chained to the first app's circumstances. Reuse a wallpaper app's data structure for a diary app, and you'll be left with stray fields like "resolution" or "category" in something that's supposed to be a diary — a source of confusion later.
For the core, carry over only the thinking that worked in app one, and write the code fresh. That separation is what keeps two apps healthy as genuinely separate creatures.
What to reuse and what to rebuild
As a rough guide for when you're unsure, here's the general split.
| Part | Approach | Why |
|---|---|---|
| Onboarding & settings frame | Reuse | Little per-app personality; aligning them eases comparison and upkeep |
| Theme (base colors & fonts) | Reuse | Keeps a consistent look; changes land in one place |
| Billing & analytics groundwork | Reuse | Shared plumbing; mistakes hit revenue and measurement directly |
| Main screen & core actions | Rebuild | The app's actual value; you don't want it chained to app one |
| Data structure & field names | Rebuild | The core skeleton; porting leaves stray fields and confusion |
| App-specific vocabulary | Rebuild | Different domain, different names; ambiguity costs you later |
When in doubt, ask yourself: "Is this the same in any app, or is it just this app's?" If the former, reuse it as scaffolding; if the latter, rebuild it as core. That one question sorts most things.
Turning "the copy" into your own foundation
By your second and third app, hunting down which project to clone from gets tedious. So take it one step further: put only the reusable scaffolding into words as your own starting point.
Concretely, write your shared onboarding, settings, theme, and billing groundwork into a template prompt you hand to Rork at the start. Instead of carrying files around, keep your "usual scaffolding" as language. That way, every new app lets you focus purely on the core, while the scaffolding arrives at the same quality each time. Running several apps in parallel, I've found this "foundation in words" to be my strongest guard against things falling apart. For designing the whole operation around multiple apps, see "A Portfolio Strategy for Passing 100K Yen a Month with Personal Rork Apps" as well.
If you're still in the middle of your first app, get a feel for finishing one with "Build Your First Rork App in 30 Minutes" first, then try this line-drawing on your second.
Before you start the second app, write out "scaffolding" and "core" on paper once, separately. That small act alone makes your future self far more comfortable. The little distinction you draw today is what keeps the growing family of apps light on its feet. Thank you for reading.