From Hikari to CoreMVP
Start with the CoreMVP foundation and assess where your existing Hikari work belongs.
CoreMVP is a separate source-code foundation. Choose it when your application needs shared workspaces, persisted Projects or one-time payments with guest onboarding. Your next step is to inspect the foundation, obtain repository access and run a new local clone.
Hikari stays free under MIT. A Starter, Pro or Business subscription in your Hikari application exercises its example billing flow; it does not provide CoreMVP repository access.
Match the foundation to your product
Hikari includes individual accounts, protected pages, recurring subscriptions, Docs and Blog. Its Organization and Project selectors are visual examples. CoreMVP adds connected collaboration and payment paths you can extend:
| Your product needs | Start with the included CoreMVP path |
|---|---|
| People working in a shared workspace | Organizations, invitations and member roles |
| Real records with shared ownership | Persisted Projects and server-checked member access |
| A one-time purchase before account creation | Guest checkout, onboarding and lifetime access |
For example, a client workspace needs more than a selected Organization in the browser. A request must identify the signed-in user, check their current membership and scope the requested data to that Organization. CoreMVP’s Projects follow that path. Any new customer-owned table you add still needs its own ownership checks.
Inspect the CoreMVP Next.js product and try the demo to explore the interfaces. The public demo labels its sample data; it is not a migration or a shared account with your Hikari application.
Start in a separate repository
- Obtain CoreMVP through the CoreMVP site, which owns source access and current commercial terms. Then follow After Purchase to claim source access and create your working repository.
- Follow CoreMVP’s Run Locally guide in that repository. Use its current configuration and migrations rather than copying Hikari’s environment file or applying both projects’ migrations to one database.
- Create a local account and verify the included path you need. The Organizations guide shows the shared workspace path; the Projects guide shows creating and managing a real record.
Keep your existing Hikari application intact while evaluating the new local clone. Configure its provider resources and application settings explicitly. Acquiring source does not include hosting or transfer your current users, subscriptions or provider state.
Bring your existing work deliberately
Before moving custom work, identify what you have changed:
- Interface and content: inventory your routes, components, styles and MDX. Compare them with the corresponding CoreMVP edit points before carrying them across.
- Application behavior: identify the services and access rules behind your features. A feature that becomes shared must use the Organization ownership path, not just a selected workspace name.
- Data: map your custom tables and relationships. Existing users, passwords, Projects and Stripe subscriptions require a separate migration design; this guide does not supply an automatic importer.
- Providers: configure the new application using its own guide. Keep credentials in ignored local configuration and verify callbacks, webhooks and hosted settings for that application.
Read CoreMVP’s Project Structure to place custom work. Start with one feature in the new repository and verify its account and data boundary before planning a production cutover.