Desifex

Watching a build

What the steps mean, what is happening underneath, and why you are not shown a log.

A build narrates itself as it goes. Each line is a step that has just happened or is happening now.

What the steps mean#

They are written in plain language, not as commands:

  • Reading what you asked for — working out what to change.
  • Setting up the database — creating or changing where records are stored.
  • Building the proposals list — writing a screen.
  • Checking it builds — compiling the application for production, which is the test that matters. A change that does not compile does not count as done.
  • Fixing what broke — it ran the application, read the error, and is correcting itself. This is normal and not a sign of trouble.

A tick means finished. A pulsing dot means in progress.

The first build has extra steps#

Creating an application does more than write code:

  1. The base application is written — a working, empty application in your design system, with the data wiring already in place.
  2. Its database, cache and container are created. Each application gets its own, and so does each environment of it.
  3. Dependencies are installed.
  4. Only then does the builder start on what you actually asked for.

Steps 1 to 3 are the same every time and are not improvised, which is why the first build is slower but not less reliable.

Why there is no log#

There is no Source tab and no Logs tab, deliberately.

A file tree and a stack trace turn an application somebody owns into one they feel unqualified to touch, and this is built for people who read neither. So command output, file contents and build logs are removed on the server, before the page is sent — not hidden in the browser, where anybody who opens the developer tools finds them anyway.

What survives is the readable build: which step is running, whether it worked, and what the builder said about it. A failure arrives as one sentence.

If a build has gone wrong in a way you cannot get past, we can see the whole thing and escalate it. And the source is always yours to download.

It saves as it goes#

Whatever reached the application is committed at the end of every run — whether it succeeded, failed, or you stopped it. Half-finished work is exactly what gets lost otherwise.

So every run leaves a version behind, and going back to one is always possible. See Versions.

Long builds#

A very large request can reach the step limit and pause rather than fail. The work is saved and Continue picks it up with the whole conversation intact.

If that happens regularly, the requests are too big. Break them up — you will get better results as well as faster ones.

Leaving the page#

A build keeps running when you close the tab. Come back and the conversation is where you left it, with the steps that happened while you were away.