Create your first app

With your machine prepared, pick a path.

Implementation

1. Recommended path: MCP

Ask your assistant:

Create a project with Kasy

Before asking anything, the assistant should offer the choice: Quick (here in chat — a few questions, full default set except Drive) or Advanced (feature by feature, terminal-only via kasy new). It recommends Quick, but either way you can add or remove features later (kasy add/kasy remove, or add_feature/remove_feature in chat) — picking Quick never locks anything in. If you prefer Advanced, it tells you to open a terminal: the MCP cannot run the interactive wizard.

If you pick Quick, it asks for name and backend (Firebase, Supabase, or REST API) and uses create_project. No terminal typing.

Expected assistant flow:

1. prepare_machine
2. check_kasy_updates → upgrade_kasy + restart the client if needed
3. configure_license if the user already has a key
4. AskQuestion: folder, backend, region (Supabase/API), push (Supabase/API)
5. create_project

For Supabase or API, the assistant asks push only (no separate Google question; Google is ON by default):

• Push yes: push=true (push + free Firebase companion for FCM; Google OAuth can be configured automatically in that step and registered on Supabase Auth).
• Push no: no Firebase companion. Google still in the scaffold; Client ID/Secret + enabling the provider on the Supabase Console: configure_google_login later.

In the terminal (kasy new interactive Quick), the CLI still asks push and Google separately. MCP includes Google by default (independent of push; same as kasy new --yes). Without a companion, credentials later via configure_google_login.

2. Alternative path: terminal

With the global CLI:

kasy new

The wizard asks:

1. Project name (creates the folder)
2. Backend: Firebase, Supabase, or REST API
3. Quick Mode or Step by step
4. In Quick (Firebase or Supabase), the CLI asks whether to connect the backend now or later. Later scaffolds the app in preview mode (navigable, no real accounts) until you run kasy backend or MCP configure_backend. Ignored for the API backend (no remote project to defer).

5. In Step by step: feature multiselect (Auth, Settings, Push, etc. on/off)

Later you can add or remove with kasy add / kasy remove (e.g. kasy add notifications creates the FCM companion on Supabase/API; kasy remove notifications removes the module and leaves NoOp stubs). Existing projects do not change by themselves; only when you run add/remove/update.

Forgot to log in? kasy new catches it and walks you through it.

3. After creating (both paths)

Firebase: deploy is separate, before the first boot:

cd your_app_name
kasy deploy
kasy run

Via MCP, ask: "deploy Firebase and run the app". It uses deploy_backend and then run_app (asks whether iOS, Android, or web).

Supabase: deploy already runs during new. Just:

cd your_app_name
kasy run

REST API: no deploy. Point BACKEND_URL in .vscode/launch.json:

cd your_app_name
kasy run

Next step: run the app.

Information

Quick Mode vs Step by step

Each project pins its own Flutter version (kasy-cli >= 1.75.0)

Every app created by kasy new (or the MCP's create_project) now locks the Flutter version used only in that project, via FVM. This avoids the classic problem: updating Flutter for a new project and breaking an old one.

It works on its own, no manual step:

1. During machine prep (kasy doctor / prepare_machine), FVM is installed if it isn't already.
2. When the project is created, the CLI resolves the current "stable" version and writes a .fvmrc file at the project root, pinning that exact number.
3. Every command the CLI runs inside that project (kasy run, kasy add/remove/update, release builds, etc.) already uses the pinned version automatically.

Projects created before this version don't get a .fvmrc automatically: the pin only applies to new projects.

Last updated on 08/23/2026