Choose a starter kit once: the six checks that prevent a full rewrite later

Most rewrites do not start with bad code. They start with a starter kit that answered the wrong question. The kit demoed beautifully, the screens looked finished, and three months later the team discovers the navigation model fights deep linking, the auth layer cannot hold a refresh token, or the state layer collapses the moment offline support arrives. At that point nobody rewrites one file. They rewrite the app.

This post gives you a decision procedure for picking a starter kit you will still be happy with at version three. It is written for builders turning an AI-generated prototype into a shippable product, and every check below maps to a rewrite trigger seen in real production apps.

Start from the shipping list, not the screen list

Kit marketing shows screens. Your rewrite risk lives in everything around the screens: authentication sessions, push registration, over-the-air updates, error tracking, build profiles, and store submission metadata. Before comparing kits, write the list of capabilities your app needs at launch. A practical starting inventory looks like this: sign-in with persistent sessions, role-gated routes, push notifications that survive token rotation, an update channel that can roll back, crash reporting tied to release versions, and separate build profiles for development, preview, and production.

Now score each candidate kit against that list instead of its screenshot gallery. A kit that ships five polished screens but leaves auth session refresh as an exercise is worth less than a plain kit with session handling already wired. If you want a ready-made version of this inventory, the production shipping checklist covers the gaps that most commonly force rewrites.

// Scorecard shape: one row per launch capability, not per screen.
// A kit passes when every row is "included" or "documented path".
type KitScore = {
  capability: string;      // e.g. "persistent auth session"
  status: "included" | "documented" | "missing";
  rewriteRiskIfMissing: string;
};

const example: KitScore = {
  capability: "persistent auth session",
  status: "missing",
  rewriteRiskIfMissing: "force-login loop after every app restart",
};

Run this for every candidate before you fall in love with any of them. It takes an hour and it is the highest-use hour in the project.

Check the upgrade path before the feature list

The second rewrite trigger is a kit pinned to versions you cannot leave. Check three things: which framework version the kit targets, whether its dependencies are pinned with a documented upgrade policy, and whether the kit itself has shipped updates in the last few months. A kit built on a year-old framework release with locked transitive dependencies is a snapshot, not a foundation. You will pay for the drift the first time a store policy or an OS release forces an SDK bump.

Concretely, open the lockfile. If major native dependencies sit two or more major versions behind current and there is no changelog explaining why, assume the upgrade will land on you mid-project. Ask the maintainer or the community how the last major framework upgrade went for kit users. Silence on that question is itself an answer. Kits that track the framework closely cost slightly more attention week to week and save you a rewrite at exactly the moment you can least afford one.

Verify auth and data against your backend, not the demo backend

Demo backends lie by omission. A kit whose auth flow works against a permissive demo project can fail against your production backend in ways that look architectural: sessions that do not survive restarts, row-level policies that block queries the demo allowed, storage uploads that fail on real mobile networks. These failures arrive late, they touch every screen, and they are the classic reason teams declare the foundation broken and start over.

The fix is to spike your real backend paths in the first week. Wire the kit to your actual auth provider and confirm sessions persist across restarts. Run one query per role against your real access policies. Upload a photo on a throttled connection. The row-level security checklist is a good template for the access-policy half of this spike. If the kit survives contact with your real backend in week one, it will probably survive launch. If it does not, you have learned that for the cost of a spike, not a rewrite.

// Week-one backend spike: pass criteria before committing to the kit.
const spikeGates = [
  "session survives app restart without re-login",
  "each role can read exactly what its policy allows, nothing more",
  "media upload completes on a throttled 3G-profile connection",
  "sign-out clears every cached credential and cached query",
];

Confirm the kit is agent-readable

If AI coding agents will extend this codebase, the kit must be legible to them: a predictable folder layout, one documented place per concern, explicit conventions for where new screens, queries, and background jobs go. Agents do their worst damage in codebases where two patterns exist for the same job, because the agent picks one at random each session. A starter kit with a single routing convention, a single data-fetching pattern, and a written contract for adding features will absorb months of agent-generated changes. One with three overlapping patterns will be unrecognizable by month two, and unreadable code gets rewritten.

Evaluate this the way an agent would: ask whether a new contributor, human or model, could add one feature using only the kit's own docs and file layout. The agent-readable repository guide describes the structure that makes this possible, and the agent acceptance checklist gives you the merge gate that keeps agent contributions safe after you pick the kit.

Demand a rollback story for updates

Whatever ships your JavaScript or native bundles needs a documented way back. Over-the-air update channels, staged rollouts, and build profiles are exactly the machinery teams skip during kit selection and miss during their first bad release. One broken bundle without a rollback plan strands users on a crash loop until a full store review cycle clears. That incident alone has triggered more than one rewrite, because leadership loses confidence in the whole delivery setup.

Before adopting a kit, confirm it documents separate build profiles for development, preview, and production, keeps secrets out of bundled code, and describes the rollback procedure for a bad update. The EAS Update rollback plan shows what good looks like on the Expo side, and the build secrets guide covers the profile split. If the kit is silent on all of this, budget a week to build it yourself or keep shopping.

Run the one-week trial that decides

Selection done on paper still needs one empirical gate. Give the winning kit a single time-boxed week: build walking-skeleton versions of your two hardest flows end to end against the real backend, run the app on a physical device over a real network, cut a preview build through the production pipeline, and hand one feature to an agent with only the kit docs as context. Pass criteria are binary. Skeleton flows work on device. Preview build installs. Agent feature merges clean. Anything that fails here fails ten times harder at launch, and a week spent rejecting a kit is the cheapest week in the project.

# One-week trial exit checklist (all must be true):
# [ ] two hardest flows work on a physical device, real network
# [ ] preview build installs from the production pipeline
# [ ] agent-built feature merges with no structural surprises
# [ ] rollback of a bad update bundle demonstrated, not theorized

The decision, stated plainly

Choose the kit that survives your shipping list, tracks its framework, tolerates your real backend, reads cleanly to agents, and can roll back a bad release. That kit will rarely be the prettiest demo. It will be the one you are still building on a year from now, which is the only beauty metric that matters.

Sources

• Expo documentation, Create a project — verified live 2026-09-06; cited for the standard project-creation baseline that starter kits build on.
• Internal: Ship an AI MVP to production checklist; Row-level security production checklist; Agent-readable repository structure; AI coding agent acceptance checklist; EAS Update rollback plan; EAS build secrets and env profiles.