Manage an App

Create, build, check, brand, and publish an App from your Wapps' data and workflows.

Apps are the public-facing counterpart to a Wapp — see Apps for the audience/binding permission model before configuring one.

A business system from the Store comes with its Apps already built. See Apps that come with a template.

Create an App

Open Apps and select New app.

Give it a Name and choose an Audience — Just me, Team, Invited, or Public. You can change the audience later.

Select Create app. Cheqq opens the App Builder, where you describe the App in chat and Cheqq designs it, binds its data, and builds it.

You can also ask for an App from the main chat, where the preview appears beside the conversation.

Apps that come with a template

A business system installs its Apps with it: a form for your website, a site, or a portal for your clients. Each is built while the Wapp is set up, already connected to the Wapp's records and automations, so a brief sent through the form lands in your records and starts the automation that answers it.

Publish them from the Wapp's Home, where each App shows Building, Ready to publish, Live or Build failed, or open one in the App Builder to change it like any App you made. Only the person who installed the Wapp can publish its Apps; everyone else sees their state and address.

A template update keeps each App connected to its automations, and never changes your App or brings back one you deleted. When the template has a newer version of an App you haven't changed, Home offers Update, which changes its draft only: a live App stays as published until you publish again. See Update an App or document you haven't changed.
Deleting the Wapp takes its Apps offline. Restoring the Wapp brings them back ready to publish, not live.
An App that couldn't be connected to its automation says so on its card on Home, with the reason.

Build with the App Builder

Describe the App in the App Builder's chat. A build keeps going if you close the tab; see Work that keeps going without you.

The builder works from the Wapps the App is bound to, and from what you give it:

Pages on the web. Paste a link — your current site, a layout you like, your own copy — and the builder reads it. It can also take a screenshot when what matters is how a page looks rather than what it says.
Your files. An uploaded logo or brand image in your workspace Files can go straight into the App.
Images and video it makes itself. The builder can generate a hero image or a background clip using your workspace's approved models, then add it to the App's own assets so the published site serves it.

Generated media is billed like any other generation in chat.

Every App starts with Tailwind CSS ready to use. The build setup itself is managed by Cheqq, so an App's code can't change how it is built.

Point at something and ask

Select the pointer button in the preview's toolbar (Select an element to ask about), then click anything in the App. It appears as a chip above the composer, and your next message is about that element — "make this bigger", "why is this empty?" The builder finds the exact spot in the App's code that draws it, so the change lands where you pointed.

Edit text and styles by hand

Select the pen button (Edit text and styles in the preview) and click an element. The Edit panel opens beside the preview — under it on a phone — where you can retype its text and change its colour, background, weight, alignment, opacity, size, and spacing. Changes show in the preview as you make them; Save writes them into the App's code, and Discard drops them; leaving Edit saves anything you haven't. Undo and Redo step through what you changed.

Some edits belong to the chat instead, and the panel says so:

Words that come from your data rather than from the page can't be retyped here.
A style worked out by code can't be changed here.
An element drawn once per item in a list changes every item.
Attributes and structure aren't edited here yet.

Code, Console, and the builder's panes

Beside Preview, the Code tab shows the App's files and the Console tab shows what the App logged, with a count when there are errors. The width buttons preview the App at desktop, tablet, and mobile sizes.

On a phone the builder has Chat, Preview, Code, and Console tabs and opens on the chat; on a desktop the chat sits beside the preview. Each pane you switch to is a step in your browser's history, so Back returns to the one you were just on.

Documents from the builder's chat

Ask the builder's chat for a document — a launch checklist, a spec, copy to review — and it opens over the preview, with a chip above the composer to reopen it. Back puts it away. See Artifacts.

The builder checks before it ships

Before the builder deploys, it opens the draft in a real browser and looks at it: the pages it changed, at phone width too when layout matters. It reads back errors, blank pages, and any data request the App's bindings would refuse, and it takes screenshots to compare with what you asked for. It can fill in forms and click through to check a flow; anything the App writes during a check is a rehearsal — nothing is saved and no workflow runs. It fixes what it finds, checks again, and deploys only once the check passes.

An App's code reaches your data through what it is bound to. Code that asks for a field or an operation the App wasn't granted fails the build, so the mistake never reaches a visitor.

Packages an App installs come from the public npm registry; nothing else is reachable while they install.

Configure bindings

Ask the builder to bind what the App needs. For each collection it binds, it chooses the operations the App allows (read, insert, update, delete) and exactly which fields it exposes — leave a field out and the App can never see or write it. A binding can also carry a filter so the App only ever sees a subset of rows, and the builder can connect a workflow's webhook trigger when the App needs to call it.

If the App needs a field or collection your Wapp doesn't have, the builder adds it to the Wapp first, or tells you exactly what's missing.

Every photo you upload to a record also gets a copy sized for a page, sharp on any screen and quick to load on a phone. The business systems' Apps show your photos that way, and the builder uses it for the large pictures in the Apps it makes.

See Audience and bindings for what each option actually permits.

Choose who can visit

The audience button in the builder's header shows the current audience — Just me, Team, Invited, or Public. Select it to open Who can visit, pick another, and Save. On a published App the change is live immediately, with no rebuild.

For an Invited App, the same dialog lists Invited guests: enter someone's email and select Invite, or Revoke someone's access. If the App is live, Cheqq emails them its link. If it isn't yet, publish it and invite them again to send the link. When Cheqq can't email them, for instance because you've sent today's invite emails, it says so, and you send them the link yourself.

They sign in with that email. Someone new to Cheqq creates an account with it, or continues with Google, and lands back on the App. A guest you revoke, or a member who leaves the workspace, loses access within a minute.

Portals: each visitor sees only their own records

A portal is an Invited App where each signed-in visitor sees only the records that carry their email: a client's own projects and invoices, a resident's own lease and repairs. The portals in business systems work this way, and you can ask the builder to make one.

What they see is only their own records, matched by their email.
What they send, like a request or a repair, is filed as theirs, whatever the form says.
What they change is limited to the fields the App allows them to set. Everything else they can see stays read-only.
Everyone else's records stay out of reach, even to someone guessing a link.

A portal needs people to sign in, so it can't be Public. See Audience and bindings.

Cheqq asks before an App reaches more

When a change the builder wants to make would let an App reach more of your records, such as every client's records instead of each visitor's own, or open it to more people, Cheqq asks you first with Allow wider access. Publishing or rolling back to a version that reaches more asks the same way. These asks wait for you even in Auto mode. When you select Deploy or Roll back yourself, that's your yes.

Set up your workspace Brand kit (logo, colors, fonts) from Apps or Settings → Brand kit, and every App you build starts from a consistent look.

Ask the builder to change the App's sign-in screen — headline, subhead, logo, custom CSS, and whether any signed-in Cheqq user may enter an Invited App without an invite. See Branded auth and domains.

Ask it too for the App's search title, description, and social image before publishing, so shared links have the intended preview. Published Apps receive a generated *.cheqq.site address.

Import your brand from your website

Your colours, fonts and logo are already on your website, so Cheqq can read them instead of you picking them again.

Open Settings → Brand kit and select Set up your brand, or Edit brand kit. In a business system, the Apply your branding step opens the same dialog.

Under Import from website, enter your site's address, like yourbusiness.com, and select Import my brand. Your home page works best. If you already have a kit, the dialog opens on it: select Import from a website at the top.

Check each step: Basics (your business name, light or dark, logo and icon), Colors, Font & style, and Guidelines for your tone of voice. The preview shows the result as you change it.

Select Save brand kit.

Nothing is saved until you do. If Cheqq can't read your site, it says why, and Create manually sets up the kit by hand instead. Fonts come from Google Fonts; where your site uses one that isn't there, Cheqq names the closest it has. Editors and above can change the brand kit.

Restyle a Wapp's Apps

Opened from a Wapp's Home, the brand kit offers Also restyle this Wapp's apps when you save, ticked to start with. The Wapp's Apps take your colours, logo and font straight away in the App Builder. A live App shows the new look once you publish it again, so nothing changes in front of your visitors until you do.

Connect a custom domain

On a Pro or higher workspace, deploy the App first, then open Domain in the builder's header (the ⋯ menu on a phone):

Enter your domain (e.g. www.example.com) and select Connect domain.

Add the verification records Cheqq shows you to your DNS provider.

Add the routing record that points your domain to Cheqq.

Status updates on its own while the dialog is open as DNS propagates; Check status asks again right away.

Rolling out

Custom domains are still finishing rollout — if you don't see the option, check back or confirm your workspace plan.

Your generated *.cheqq.site address keeps working even if you later remove the custom domain.

Preview and publish

Use the App Builder's preview to check changes before they go live. Previewing your own unpublished App uses a short-lived, App-scoped session that does not affect visitor sessions or make the App public.

Select Deploy to publish. The button reads Publishing… until the new version is live or the build has failed; pressing it again while a build runs doesn't start a second one. Publishing brings every part of the App up to date and refreshes its thumbnail from the live version.

Versions lists every published version. Select Roll back beside an earlier one to put it live again at once — or ask the builder to. Rolling back doesn't change your draft, so fix it before deploying again. Unpublish takes the live address down; the source, draft, and version history stay in the builder.

Remix an App

Fork a public App you can access as a starting point, then customize it independently. A remix is private and unpublished, does not inherit the source App's domain or visitors, and keeps a reference to the App it came from.

Chat in the App Builder uses the same per-turn checkpoints as other chat surfaces. Restore affects draft source and configuration only—it does not undo an existing deployment, domain, or published visibility. Forking a checkpoint creates an independent unpublished App when the artifact must be duplicated. See History and recovery.

To show someone how an App was built, share the builder's conversation as a replay — see Share and remix.

Related: Manage a Wapp for the Wapps an App draws on.