Build a Kareenos Agentic Web-App

A Kareenos Agentic Web-App is a web application built with Claude Code and hosted by Kareenos at its own address: https://<app name>.kareenos.com. It can be for your own customers, who register in it, or for your own team, who sign in with their Kareenos login. Kareenos is its backend, its automation layer and its host. You describe the application, and Claude Code writes both the screens and the server logic that serves them.

Its companion is the Kareenos Agentic Business Project, the operation your own team runs inside the Kareenos console: sheets, jobs, agents, widgets, pages and reports. The two are not alternatives. A Web-App keeps its data and its logic in a Business Project, so building one normally means building both.

Where to find it#

Apps is a row of level 3 (K-Apps); it opens the Apps & K-APIs page. Press Open in Kareenos above. Every application your account publishes appears there with its address, its routes, its users and its versions. Registering an application needs an account administrator. Claude Code needs the connector from Connect Claude Code.

How the pieces fit#

A Web-App has two layers, and Claude Code builds them together, feature by feature:

• The screens. A single-page web application (Vue 3 with Quasar is the recommended stack). It runs in your users' browsers and is served by Kareenos.
• The settings. The screens carry no settings of their own. When Kareenos deploys a version it writes a small public file, /kareenos.config.json, next to the screens: the application key, the address and the API origin. The screens read it when they start. The same bundle therefore works under any application, which is what lets a Web-App and its build travel through the marketplace unchanged. Claude Code asks the connector for the same file to use while developing.
• Who signs in. Every application has an authentication mode. Your app's own users: customers, members or partners register in the application and are kept for you as app accounts. Kareenos users: your own team signs in with the same email, password and verification as in Kareenos, and every route runs as that person with their own permissions; the application never registers anyone. Claude Code settles this before it registers the application, from what you told it, and states its choice so you can correct it.
• The routes. Each thing a screen needs to do (sign up, sign in, list my orders, place an order) is a route. A Kareenos-users application needs no sign-in route of its own: Kareenos provides it. A route runs an automated job you own, and that job is the door to everything in your account: it reads and writes your sheets, sends a WhatsApp message or an email, asks one of your agents a question, raises an event other agents react to, records a location, and more. The screens never touch any of that directly.

Because the routes are yours, the application's data lives in your Live Workbooks, next to everything else. Your dashboards, reports and agents see the same rows the application writes, and the in-app Super Agent can extend the application later. Claude Code is told, in the connector's own guide, never to keep application data anywhere else.

Step by step: from an empty folder to a live address#

1. Tell Claude Code what the application is for and who its users are: your customers, or your own team. Ask it to read the connector's guide first (it does this on its own with kareenos_context).
2. Claude Code registers the application. The name becomes the address: lowercase letters, digits and hyphens only, and it must be free across the whole platform. acme-shop becomes https://acme-shop.kareenos.com.
3. Claude Code builds each feature in order: the sheet, the route and its job, then the screen, then a test call of the route. Review the plan it proposes before it starts.
4. Claude Code builds the screens into a bundle and pushes it as a version. The push goes live right away unless it was asked to stage it.
5. Open the address in a browser and try the real flows: sign up and sign in (or, for a team application, sign in with your Kareenos account), then the business screens. Report what to change and let Claude Code push the next version.

Managing versions yourself#

From Apps, press Versions on an application to see every pushed version, which one is live, who pushed it and when. From there you can:

• Activate an older version to roll back, or a staged one to go live.
• Redeploy the current version if the address is not serving what you expect.
• Upload a bundle by hand (a zip of the build output with index.html at its top level).
• Probe the address to confirm it serves the current version.

Disabling Hosting on an application takes the address down while keeping its routes and users; disabling the application takes both down. Deleting an application removes its versions and its users. Prefer disabling when in doubt.

Common mistakes#

• A name that is taken or invalid. The address must be a free, valid label. Claude Code gets a clear message and picks another.
• Zipping the wrong folder. The bundle must contain index.html at its top level. Claude Code zips the build output folder, not the project folder.
• Expecting the address to change instantly. A new version is picked up on the next page load, within seconds. Press Probe in Versions to confirm.
• Baking the application key into the screens. The push still succeeds, with a warning, but such a bundle only ever works for one application and the marketplace will not carry it. Claude Code is told to read /kareenos.config.json instead.
• Keeping data in the browser or in a private table. Application data belongs in sheets. If a screen needs data, it needs a route.
• Building a sign-up screen for a team application. A Kareenos-users application has no sign-up. People join on the Teams page of Kareenos, and the application signs them in with their Kareenos login.

Next#

• Apps and K-APIs
• Builder guide for MCP clients
• Data Sheets