Why IsotopeKit
Stop forking starters. Compose packages.
Most Next.js SaaS kits age into merge hell. IsotopeKit keeps platform code in versioned @isotopekit/* packages so your product app stays thin and upgradeable.
Forked starter vs package-composed kit
| Issue | Typical kit | IsotopeKit |
|---|---|---|
| Who gets billed? | The user account (good luck with multi-org) | The organization — one subscription per workspace |
| AI / agent onboarding | Hope ChatGPT guesses your folder structure | AGENTS.md, _docs specs, and Cursor skills included |
| Payment provider lock-in | Rewrite checkout when you switch vendors | BillingProvider adapter — swap keys in the app wire, keep UI |
| Checkout state | Fake pending plan rows or metadata hacks | billing_status enum — real plan_id from day one |
| Entitlements & metered usage | Hardcoded limits in components | JSON catalog + add-ons + credits pool per org |
| Agency / white-label | Build it yourself (6 months, maybe) | Hub + client accounts + pool distribution built in |
| Platform updates | Git-merge upstream and pray nothing broke | pnpm update @isotopekit/* — semver + stable extension points |
| Customizing the kit | Fork the whole repo and merge upstream forever | isotopekit.config.ts + @isotopekit/* packages — extend, don't rewrite |
What you own vs what you depend on
- You own: routes, env, product pages, and the composition root that wires packages.
- You depend on: versioned packages for auth, orgs, billing, admin, and agency — updated with
pnpm update @isotopekit/*.