Skip to main content

App Builder

The App Builder turns your agents, tools, and AutessaDB tables into real web apps. Describe what you want in chat and the AutoBot writes a full React app for you — or open the built-in IDE and edit every file yourself — then publish and share it, up to and including a public URL.

What it's for​

Agents are great, but your users often need an interface: an intake form, a client portal, an internal dashboard, a chat frontend. The App Builder hosts that interface on Autessa. Apps run in a sandbox with scoped credentials, so a hosted app can invoke exactly the agents, tools, and tables you allow — nothing else.

From the dashboard, select App Builder in the sidebar. Apps are listed under the usual ownership tabs — Owned By Me, Shared With Me, and Company Wide. Users with viewer-only access see the same section as Apps, listing published apps they can launch.

Open App Builder →

Key concepts​

  • Apps are React apps — each app is a set of JSX/TSX/CSS files with an App.jsx entry point, bundled live in the editor with an instant preview. npm packages are available, and internal navigation uses standard React routing.
  • Starter templates — every new app begins from a template you pick at creation: Landing Page (a polished marketing site with hero, features, pricing, and FAQ sections built from reusable blocks), SaaS Application (a modern product-app shell with light/dark themes and a full built-in component library — buttons, tables, modals, toasts, and more), or Dashboard (an analytics starter with KPI tiles, charts, and data tables). The SaaS and Dashboard templates include a live Components page showing every built-in component, and AutoBot reuses the same components when it writes new pages, so the app stays visually consistent as it grows.
  • AutoBot (vibecode) — the in-editor AI assistant. It reads your files, your published tools and agents, and your AutessaDB schemas, proposes a plan, and writes the code as reviewable diffs you Apply or Reject (or turn on auto-apply). A "mock only" mode builds frontend-first against mock data. See Vibecode.
  • The editor — a three-pane IDE: file tree, Monaco code editor with auto-save, and a live preview with console. You can export the whole app as a ZIP or import files back in. Prefer chat-only building? Hide Code collapses to just AutoBot plus the preview.
  • Versions — file edits always target the draft. Publish builds and promotes a published version; Version History shows published and archived versions with one-click rollback to any successful build. Apps can also be managed programmatically through the Custom Apps Poweruser API.
  • Sharing vs hosting — two separate dials. Sharing controls who can open the code (private, specific teammates, or company-wide, with Read/Write/Publish/Admin levels). Hosting mode controls how end users run the published app: default (Autessa login required), Public (anyone with the link), Access Code, Custom Auth (app-specific accounts backed by an auto-created AutessaDB table, with a themeable sign-in page and optional Google and Microsoft sign-in), or Personal access links (each person gets their own private link, with no password). See End-user sign-in.
  • Public slugs — non-default hosting modes get a public URL like https://public.autessa.com/app/your-slug.
  • Runtime permissions — in App Settings, hosted apps declare exactly which resources they may touch at runtime: AutessaDB tables (read/write/delete per table), agents, tools, managers, e-signature envelopes, and any admin API endpoints. The app receives scoped credentials for just that list.

How to build an app with AutoBot​

  1. In App Builder, click New App, give it a name and optional description, and pick a starter template — Landing Page, SaaS Application, or Dashboard. The editor opens with the template's scaffold ready to customize.
  2. Click AutoBot and describe the app — "a support portal where customers chat with my SupportAgent and past tickets load from my Tickets table."
  3. AutoBot inspects your published agents, tools, and table schemas, proposes a plan, and streams file changes. Review the diff and click Apply Changes (or enable auto-apply).
  4. Watch the live preview update; keep iterating in chat, or hand-edit any file directly in the editor.

Want this as a guided walkthrough? Build your first app takes you from an empty workspace to a published todo app — complete with an agent that files your email as tasks overnight.

How to publish and share​

  1. Click Publish. Autessa builds the app server-side and promotes the draft to the published version; the build status is shown as it runs.
  2. Open Share to set who can access the app's code and pick a hosting mode for end users. For Public, Access Code, Custom Auth, or Personal access links hosting, choose a slug to get your .../app/your-slug URL.
  3. For hosted modes, open Settings → Permissions and grant the app exactly the tables, agents, tools, and endpoints it needs at runtime.
  4. If something breaks after a publish, open Versions and roll back to a previous successful build.

Publish access follows the same access levels as every other resource — you need PUBLISH or ADMIN on the app, and end users only ever see the published version.

End-user sign-in​

Two hosting modes give every end user their own identity inside the app.

Custom Auth: accounts with email, Google, or Microsoft​

Custom Auth apps keep their end users in an AutessaDB table that Autessa creates for the app. Under Sign-in methods in the Share settings, choose any combination of:

  • Email and password. Visitors sign up with an email address and password. You can require them to confirm an emailed code first.
  • Google. Visitors choose Continue with Google and sign in with their Google account.
  • Microsoft. Visitors choose Continue with Microsoft and sign in with a work, school, or personal Microsoft account, including Outlook.com.

At least one method must stay on. There is nothing to set up with Google or Microsoft: Autessa handles the connection. The first time someone signs in with Google or Microsoft, a row for them is added to the app's user table. If that email already has a password account and Google or Microsoft confirms that the person owns the address, both sign-in methods open the same account.

With Personal access links, nobody creates an account or remembers a password. You add the people who should have access, and each one gets a private link. Opening the link signs them in, and the app knows exactly who they are.

  1. In Share, pick Personal access links and choose a slug.
  2. Click Manage access links, then Add people. Add one person at a time, or paste a list with one Name, email per line. Email and an expiry date are optional.
  3. Copy each person's link, or use Copy all, and send the links however you like.

Every link also contains a 16-character code that people can type on the app's sign-in page. From Manage access links you can copy a link again at any time, Rotate it to issue a new link and stop the old one, or Revoke it to shut that person out.

People are stored in an AutessaDB table created for the app. Add your own columns to that table, such as team, role, or region, and the app can read them for whoever is signed in.

Knowing who is signed in​

In both modes the app can read the signed-in person through the Autessa SDK built into every app. The person comes back with their ID, name, email, and sign-in method. For personal access links, the result also includes every custom column from their row. Tools and agents that the app calls receive the same person as @@{appUserId} and @@{appUserEmail}, so a tool can scope its work to the user. In row security rules, use $CURRENT_CUSTOMAPP_USER_ID for Custom Auth accounts and $CURRENT_CUSTOMAPP_ACCESS_LINK_ID for personal access links. The two never match each other, so switching an app between modes can't expose one person's rows to someone else.

Custom domains​

Both modes work on a custom domain. Visitors sign in on the Autessa sign-in page and land back on your domain at the page they started from. Personal access links point at your custom domain automatically once it is active.

How long visitors stay signed in​

A visitor stays signed in until they go a set time without opening the app. Each visit starts the clock again. By default that's 8 hours for access code apps and 24 hours for Custom Auth and personal access links. To change it, open Share, find Keep visitors signed in for, and pick anything from 1 hour to 30 days. The new length applies to people who are already signed in the next time they open the app. Team-only apps (the default hosting mode) use the company's Autessa sign-in instead. See Team.

Signing out​

Apps let people sign out through the sign-out call in the Autessa SDK. Signing out ends the person's session, forgets it in their browser, and returns them to the app's sign-in page with a note that they've been signed out, so the next person on a shared computer starts fresh. It works in every signed-in mode (access code, Custom Auth, and personal access links), both on Autessa and on a custom domain. The newer starter templates include a Sign out button that appears only when someone is signed in. Public apps and apps opened inside Autessa have no app sign-in, so the button stays hidden there. When you ask AutoBot to build a signed-in app, it adds a sign-out action for you.

Sharing and access levels​

Every app starts private to its owner. Share it with specific teammates — each at their own access level — or company-wide at a single level for everyone. The levels carry app-specific meanings:

LevelWhat it lets a teammate do
READLaunch the published app and clone it — viewer access, no source code
WRITEOpen the editor, read and edit files, and see builds and versions — builder access
PUBLISHPublish the app
ADMINShare, delete, and transfer the app

The owner always has ADMIN implicitly; unlike most resource types, an app's ownership can be transferred by any ADMIN, not only the owner. Remember this dial governs teammates in the builder — end-user access is the separate hosting mode.