> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kazzle.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Bouwen en publiceren

> Apps bouwen met de AI, itereren op een live preview, en implementeren naar productie.

## Een app maken

Twee manieren:

* **Vraag de AI** - beschrijf wat je wilt in een thread en de AI bouwt het
* **Knop Nieuwe app** - klik op **+** in de Drive-zijbalk en kies **Nieuwe app**

De AI kiest een startsjabloon op basis van wat je vraagt:

| Sjabloon  | Wat je krijgt | Gebruik wanneer je nodig hebt           |
| --------- | ------------- | --------------------------------------- |
| `ui`      | React web-app | Een web-app, dashboard, landingspagina  |
| `process` | HTTP-server   | Een API, webhook-handler, geplande taak |

## Één app, één branch

Elke app is een enkele git-checkout op `main`. Er zijn geen aparte concepten, geen branch-wisseling, geen merge-stap. Elke bewerking landt op `main` als een commit; publiceren is gewoon "implementeer de huidige `main`".

## De build-cyclus

1. De AI schrijft code rechtstreeks op `main`
2. De AI start de dev-server. Je ziet een live preview.
3. Je itereert via chat: "verplaats de grafiek naar de zijbalk", "voeg een donker thema toe"
4. De dev-server laadt hot na elke bewerking
5. Wanneer klaar, publiceer

## Publiceren

Publiceren implementeert de huidige `main`-commit. Er is geen aparte productie-branch — de meest recent gepubliceerde commit op `main` is wat live is.

Wanneer je naar de catalogus publiceert zodat anderen het kunnen installeren, ontvangt je app een gebruikersidentiteitstoken bij het starten, een installatietoets voor de backend, en install/uninstall-webhooks. Zie [Publiceren](/apps/publishing).

## Caching, updates en offline

Desktop en mobiel openen je app-URL alleen in een normale browserweergave. Ze wissen **niet** browsercaches, forceren geen network-only-loads, en kiezen geen ander cachebeleid voor openbare versus privé-apps.

Je web-app beheert caching:

* HTTP `Cache-Control`-headers voor documenten en assets
* Optionele service worker / PWA-setup (sjablonen leveren `vite-plugin-pwa` met auto-update)
* Of een nieuwe build onmiddellijk activeert, eenmaal opnieuw laadt, of wacht tot de volgende opening
* Offline-fallback voor de meest recent geactiveerde build

Wanneer Kazzle een nieuwe gepubliceerde versie ziet voor een open app-tabblad, vraagt het de geregistreerde service worker om op een update te controleren (`registration.update()`). Apps zonder service worker negeren die controle en blijven hun eigen HTTP-cacheheaders gebruiken.

Gepubliceerde apps kunnen daarom onmiddellijk uit cache openen, een nieuwe build oppikken zonder hard refresh, en de meest recente build offline beschikbaar houden.

## Implementeren

Na publiceren, implementeer om een live URL te krijgen:

* **Remote apps** implementeren naar Kazzles cloud en krijgen een openbare URL
* **Lokale apps** installeren op je computer. De UI laadt rechtstreeks, en het process-gedeelte voert een dev-server uit.

## Realtime-apps

Voor apps die directe lokale leesbewerkingen en offline-ondersteuning nodig hebben, doet de AI:

1. Maakt een database
2. Zet realtime-synchronisatie aan
3. Bouwt een app met twee delen: UI (React + sync-client) en Process (token-eindpunt + sync-upload)
4. Verbindt inloggegevens via de [vault](/work/vault)

Zie [Realtime-synchronisatie](/apps/sync) voor hoe het werkt.

## Landingspagina's

Landingspagina's zijn UI-only apps. Geen backend, geen database. Beschrijf de pagina en de AI bouwt het, implementeert het, en geeft je een live URL. Om een aangepast domein te gebruiken, wijs je domein of subdomein naar de geïmplementeerde app-URL.
