# Grok Build: A generated app becomes a different object when published

How Grok Build’s move from an in-chat preview to published apps changes artifact identity, audience and the evidence needed to review a generated application.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-08-19
Original announcement: https://x.ai/news/grok-build-for-everyone
Canonical URL: https://retrivium.ai/retrospectives/grok-build-everyone-preview-to-published/

The August Grok Build expansion includes publication and sharing beyond the chat where an app was created. This is a useful retrospective point because a generated preview and a reachable application are different stages of the same workflow.

## The dated path

- 2026-07-15: [Grok Build is Now Open Source](https://x.ai/news/grok-build-open-source).

- 2026-07-28: [Introducing Build Mode](https://x.ai/news/grok-build-mode).

- 2026-08-19: [Grok Build expands to web and mobile on every plan](https://x.ai/news/grok-build-for-everyone).

## The artifact leaves the creator’s immediate context

A preview can depend on the conversation, current session and assumptions the creator has not written down. A published app is encountered by people who may have none of that context. Our interpretation is that the publication step makes those dependencies part of the acceptance question. The relevant test is not only whether the creator saw a working screen, but whether the reachable version behaves as intended under the audience and access conditions chosen for it.

## A link changes the audience without explaining every capability

The source announcement describes publication and audience choices. A retrospective should not infer every authentication, persistence or runtime property from the existence of a link alone. Those properties need evidence from the actual artifact and its stated configuration. This is an architectural distinction, not a claim that the release fails to provide them. The useful question is which part of the in-chat demonstration transfers to the published object and which part needs a separate check after the object becomes reachable.

## A counterfactual outside the author’s session

Open the intended published version in the appropriate independent access context and perform the tasks used to accept the preview. Compare data state, required permissions and behavior after returning later. This can reveal a dependency hidden by the creator’s live session. The test should preserve the version being examined, since editing the app after publication can otherwise make the comparison ambiguous. A working link is evidence of reachability; a functional acceptance test establishes a different and more useful claim about the application behind it.

## What the earlier milestones explain

The earlier limited Build Mode and open terminal harness provide distinct context for the later broader consumer surface. They should not be collapsed into one identical execution environment. Infrastructure can preserve the relationship between creation session, artifact version and publication state. The August announcement marks an expansion of the workflow, not automatic validation of every generated app. The broader historical lesson is that creation and distribution are connected stages with different acceptance requirements. A useful generated application needs a clear identity after it leaves the conversation that produced it.

## Technical background

Related engineering context: [Artifact revision context](/journal/aider-git-dirty-tree-undo/); [Functional acceptance](/journal/inference-benchmark-method/).