How a build works
Each request goes through the same steps: a short plan, a first look at your app within about half a minute, the build, a full test of the app, fixes, and a short summary. Here is what Crisp does at each step and what it checks before it says it is done.
Updated
On this page
A build starts when you send a message and ends with Crisp's final reply. You can watch every step in the chat.
Setting up a new project#
The first time, Crisp gives your app its own project. Crisp keeps a few projects ready in advance, so this usually takes about a second, and the build starts at once. When many people start at the same moment, it can take up to about fifteen seconds. A card titled Setting up your project shows the progress.
The plan#
Crisp's first message is a short plan you can read in a few seconds: the pages, the data, the look, and any assumption it made. When something is not clear, Crisp makes a sensible choice and tells you what it chose. If you do not like a choice, ask for a change when the build is done.
Only when a request could mean two very different things, and a wrong guess would waste the work, Crisp builds what it can and ends with a question. The question shows as a card with up to four answers. Press one, or press Type my own answer. Your answer is sent as your next message.
Crisp also keeps a list of every feature you have asked for in this project. It uses the list on later requests, so a new change does not break an earlier feature.
For a new web app, Crisp then writes a short design brief for your idea: its colours in light and dark, its fonts, the shape of its buttons and cards, its page layout, and the style of its images. The whole app follows it. Your web app opens in your visitor's system theme, and a switch lets them choose system, light or dark.
The build#
Crisp builds in an order that shows your app as early as possible:
- The first look, within about half a minute: the colours, the fonts, the navigation and the main page with real text for your idea. Records on this first page can be examples until the next step.
- The data your app saves, with realistic sample records.
- The main page, now showing the saved records.
- Forms and other things you click or fill in.
- The other pages.
- Sign-in and connections to other services, when you asked for them.
When a build changes several screens of a web app, a stronger AI model looks at them on a phone and a computer, in light and dark, and lists what to improve. Crisp fixes those points before it tests your app.
While Crisp works, one progress card in the chat shows where the build is:
- A line in plain words that says what Crisp is doing now, such as Building the /sessions/new page or Checking the code.
- Step 2 of 4 when Crisp made a checklist, the time so far, and about how much the request has cost so far.
- The checklist, and the newest steps. Earlier steps fold away under Show 5 earlier steps. A step that failed stays in the list, in red, even when a later step fixed it.
- Under a step that changed a file, the file name in small type. Click it to open the file in the Code tab. Click the step itself to see the change or the output.
When the build is done, the card folds to one line, for example Built in 4 steps · 12 actions · Thought for 9s. Click it to open it again. If you opened or closed the card yourself during the build, it stays the way you left it.
The preview reloads about a second after a file changes, so you can watch the app grow. If the preview stops during a build, it starts again by itself within a few seconds.
What every new app includes#
- Several pages with a navigation bar.
- A database, filled with realistic sample records so the pages are not empty.
- Colours chosen for your app, with a light and a dark theme.
- A layout that works on phones first, then on larger screens.
- Helpful empty states, checks on form fields, and a question before anything is deleted.
The checks#
Before Crisp says a build is done, it checks the app:
- The code passes the framework's checks, and every page loads.
- A separate tester opens the app in a real browser and uses it like a person: it follows the main paths, saves records and checks that they are still there, and tries unusual input.
- The tester also looks at every page at phone width and in the dark theme, and reviews screenshots for layout problems.
For a very small change, such as new wording on one page, Crisp checks only the page it changed.
When something fails#
- Crisp fixes the problem and tests again, up to three rounds in one build.
- If the same error comes back three times, Crisp stops. It explains the error in plain words, says what it tried, and gives you two or three options.
- Crisp never fakes or removes a feature you asked for to make an error go away. If something is blocked, for example because it needs a key from another service, it keeps the rest working and tells you exactly what is missing.
The final reply#
The build ends with one short paragraph: what Crisp built or changed, what to try first in the preview, and anything that is not working or waits on you. Under it you see how long the build took and what it cost, for example Done in 3m 4s · $0.42.
Limits#
- One build runs at a time in each project. Messages you send during a build wait in a queue, or replace the build if you send with Ctrl and Enter. See Change your app.
- You can stop a build at any time with the Stop button. See Change your app.
- Each request has a spending limit. When it is reached, Crisp pauses and you choose whether to continue. See How AI usage is charged.
- A very long build stops on its own. If that happens, see A build stopped or failed.
Related pages
Something wrong or missing on this page? Tell us. A person reads every message.
Report a problem