Designing Seams That Survive AI Regeneration in Rork

Implement the boundary: move service and store out of the screen

Let us make this concrete. Assume a React Native (Expo) project generated by Rork. The same layering holds for the Swift that Rork Max produces.

Move the logic worth protecting into three kinds of files, all living outside the screen.

First, the types. This is the promise that connects one layer to the next.

// src/domain/types.ts — you own this. Off-limits to the AI.
export interface PurchaseState {
  isPremium: boolean;
  purchasedAt: string | null;
}
 
export interface PurchaseService {
  restore(): Promise<PurchaseState>;
  buy(productId: string): Promise<PurchaseState>;
}

Next, the service. The billing implementation is sealed in here. Network retries, and the decision to withhold access on failure (deny by default), all resolve inside this single file.

// src/domain/purchaseService.ts — you own this.
import type { PurchaseState, PurchaseService } from './types';
 
const FALLBACK: PurchaseState = { isPremium: false, purchasedAt: null };
 
export const purchaseService: PurchaseService = {
  async restore() {
    try {
      const res = await fetch('https://api.example.com/purchase/restore');
      if (!res.ok) return FALLBACK; // when unsure, treat as non-premium
      return (await res.json()) as PurchaseState;
    } catch {
      return FALLBACK; // never widen access on a failed request
    }
  },
  async buy(productId) {
    const res = await fetch('https://api.example.com/purchase/buy', {
      method: 'POST',
      body: JSON.stringify({ productId }),
    });
    if (!res.ok) throw new Error('purchase_failed');
    return (await res.json()) as PurchaseState;
  },
};

Then the store that holds state. Here I use Zustand v5. The screen ends up doing nothing but calling this hook.

// src/domain/usePurchaseStore.ts — you own this.
import { create } from 'zustand';
import type { PurchaseState } from './types';
import { purchaseService } from './purchaseService';
 
interface PurchaseStore extends PurchaseState {
  restore: () => Promise<void>;
  buy: (productId: string) => Promise<void>;
}
 
export const usePurchaseStore = create<PurchaseStore>((set) => ({
  isPremium: false,
  purchasedAt: null,
  restore: async () => set(await purchaseService.restore()),
  buy: async (productId) => set(await purchaseService.buy(productId)),
}));

That is everything you own. The three files under src/domain/ hold every decision your app makes. And none of them are affected no matter how many times the screen is rebuilt.

Keep the screen down to "just call it"

The screen side, the part you hand to the AI, becomes surprisingly thin.

// app/home.tsx — a region the AI is free to regenerate.
import { View, Text, Button } from 'react-native';
import { usePurchaseStore } from '../src/domain/usePurchaseStore';
 
export default function HomeScreen() {
  const { isPremium, buy } = usePurchaseStore();
  return (
    <View>
      <Text>{isPremium ? 'Premium member' : 'Free plan'}</Text>
      {!isPremium && (
        <Button title="Buy" onPress={() => buy('premium_lifetime')} />
      )}
    </View>
  );
}

If this screen is rebuilt wholesale, all you lose is the layout. As long as the single line that calls usePurchaseStore and the intent behind the isPremium branch remain, the billing logic sits safe in src/domain/. Even if the AI drops the branch, the blast radius is "one display element changes"; the check itself never breaks.

Placing Before and After side by side makes the difference in protection obvious.

Say "rebuild just this screen" safely

With a boundary in place, your instructions to Rork become concrete and safe. Instead of a vague "fix it," you can name the exact region that is fair game to rebuild.

Rebuild only the layout in app/home.tsx into two columns.
Treat everything under src/domain as read-only and change nothing there.
Keep the usePurchaseStore call and the isPremium branch in place.

The point is that what you want protected is now a clear unit: a directory. This is not the kind of instruction the AI has to interpret, like "don't touch that color." Pointing at the src/domain boundary conveys the intent unambiguously.

The type contract then acts as a safety net. If the AI writes a screen that ignores the shape of PurchaseState, TypeScript raises an error immediately. A change that crosses the boundary is reported back to you at compile time. You get a state where the type system catches it, rather than relying on how carefully you worded the prompt.

What long-term use taught me: the danger of over-drawing

As an indie developer running several apps of my own, having put this design into six of them and lived with it for a while, I have seen the risk of overdoing it just as clearly as the benefit.

One trap is slicing the boundary too finely. If you spin up a service layer and a store for every single screen, files multiply and the whole thing stops being legible. What you protect should only be "things that hurt when rebuilt." Ephemeral display-only state does not need to be promoted into src/domain. When in doubt, ask whether a mistake would damage money, trust, or data consistency.

Another is the temptation to cross the boundary. In a hurry, you want to write a fetch straight into the screen. Do it once, and the next regeneration erases that logic. A boundary only means something when you keep honoring it. I added a small lint rule that forbids fetch calls under app/, letting a machine watch for my own weak moments.

And the boundary does not need to be perfect from the start. Move your most painful logic, usually the billing check, out of the screen first. That alone removes the worst of what you were losing on every regeneration. Once you have felt the effect, widen it to data fetching, networking, and storage a little at a time.

Closing: pick the one thing to move out today

From development you protect with prompts, to development you protect with structure. The shift to drawing a boundary pays off quietly as you spend more time with a tool like Rork that regenerates again and again.

If there is one thing to do today, it is to find the logic you most dread having rebuilt, usually the billing check, and move it into a single folder called src/domain/. Let the screen only call it. The next time you ask Rork for a screen change and confirm that the logic came through intact, this design has started to take root in your app.

Give the generated screen a core, one layer deeper, that never gets rebuilt. I am still finding my way with this, but having that core alone has let me widen what I trust the AI with, without worry. Thank you for reading.