# Start here (https://lazyfrog.dev/docs/guide/start-here)

{/* Generated by scripts/generate-docs.ts from services/gateway/src/guide.md. Do not edit. */}

1. `project_read` `list` to see the user's projects, or `project create` (name, template) to start one.
   Templates are starting stacks, not apps: `nextjs-app` (Next.js 16, React 19, TypeScript,
   Tailwind CSS 4, PostgreSQL), `python-fastapi` (FastAPI, uvicorn, psycopg), `static-site` (HTML
   and CSS) and `blank` (a database and nothing else). Another stack (SvelteKit, Astro, Remix,
   Django, Rails, Laravel, Phoenix, Go, Rust, .NET, Spring…): start from `blank`, pin the toolchain
   in `.tool-versions` (mise installs any language: `go 1.27`, `ruby 3.4`, `java temurin-21`…; PHP 8.5
   with Composer is already installed; Erlang compiles on first use, several minutes on a
   paid plan, and another PHP version longer: run `mise install` with `exec` `background: true`
   and follow it with `job`), use
   the framework's own generator and commands, and point `services.json` at them (`dev`, `build`,
   `start`, the port from `$PORT`, a `migrate` command if the framework has one), and rewrite
   `Dockerfile` and `compose.yml` for the stack: never just delete them, they are how the code runs
   outside LazyFrog (preflight warns without a Dockerfile). Existing code:
   `project import` from its repository; a prototype made in the chat (a Claude artifact, a
   ChatGPT preview or Site): see "Make it real: from a chat prototype to a project".
2. Read `README-for-AI.md` in the project (`fs_read`, path `workspace/README-for-AI.md`) for the
   template's specifics.
3. Build with `fs_write` / `fs_edit`, run things with `exec`, check with `http_get` and
   `preview_screenshot`, and read `logs_tail` when something fails.
4. Whenever you install or set up an app the owner will use (CMS, shop, dashboard, admin tool),
   call `project` `about` with where to sign in or manage it (the admin or login address), what
   it is and its version, where its data lives, how to update it and what the owner must do
   next; credentials go in `secrets`, never here (write "Admin password: stored as secret
   WP_ADMIN_PASSWORD, change it on first login"); keep it current when anything changes. The
   owner sees it at the top of the project's page, and `project_read` `get` shows it to the next
   session. Put the site's conventions in its facts too: the currency prices are in, the
   languages, the time zone, who the visitors are, so the next session keeps them.

Every tool takes `project` (slug or id). The workspace wakes automatically (about a second) when a
tool needs it and sleeps after 15 idle minutes; files, databases and logs are kept.

**On Free there is a preview and no live site.** Build it, check it with `preview_screenshot`,
and show the user the preview's own address (`project_read` `get`: `https://p-….lazyfrog.app`).
Anyone with that link can open it while the month's preview hours last (40 on Free; past them it
still wakes for your tool calls, not for visitors); it sleeps after 15 quiet minutes, search
engines don't list it, and it carries the small "Built with LazyFrog" badge. Going live (a
publish, the site at `https://<slug>.lazyfrog.app` or the user's own domain) needs a paid plan:
when the user asks to publish, or wants an address to give out, say so plainly once, in their
words ("Going live needs a paid plan. Your preview stays free: share its address while it's
awake. Upgrade to put it at `<slug>.lazyfrog.app` or your own domain.") and give the plans page,
https://app.lazyfrog.dev/upgrade (the `upgrade_url` of the refusal). Don't keep raising it, and
never present the preview as the finished, public site. `account` `get` says the plan; a
publish on Free is refused with `plan_limit` and `limit: "live_sites"`. A Free project nobody
works on for 14 days (their own actions: your work for them, the portal, signing in; visits to
the preview don't count) is archived after two emails, and can be brought back.