Das Video auf der eigenen Landingpage einer Bolt App hat eine engere Aufgabe, als die meisten Menschen ihm zutrauen. Es ist nicht da, um das Produkt zu erklären. Das erledigen die Überschrift und die Unterzeile bereits. Die Aufgabe des Videos ist es, die Überschrift in der Zeit glaubwürdig zu machen, die ein Besucher braucht, um sie zu überfliegen, bevor er entscheidet, ob er weiterliest. Das bedeutet, das Video muss die App selbst zeigen, wie sie genau das tut, was die Seite behauptet, ohne den Besucher warten zu lassen oder etwas erschließen zu müssen.
Bolts eigener Build-Prozess prägt, was "die App zeigen" hier überhaupt bedeutet. Ein in Bolt gebautes Projekt läuft zunächst in einer sandboxed In-Browser-Sitzung, der Art von Umgebung, die es dem generierten Code erlaubt, ohne separaten Server auszuführen, und diese Sitzung ist nicht automatisch eine stabile öffentliche Adresse. Zu einer URL zu gelangen, die eine Kamera wert ist, bedeutet meist den expliziten Schritt, das Projekt zu deployen, meist an ein Hosting-Ziel, das nach Abschluss des Deploys eine öffentliche Adresse zurückgibt. Gegen die temporäre In-Browser-Sitzung aufzunehmen riskiert, etwas festzuhalten, das später nicht mehr genauso aufgelöst wird, wenn sich ein Besucher von der Landingpage aus durchklickt.
Diese Unterscheidung übersieht man leicht, weil die In-Browser-Sitzung während des Bauens genau wie die deployte App aussieht und sich auch so verhält. Nichts an der sandboxed Vorschau signalisiert, dass ihre Adresse temporär ist, sodass ein Builder, der schnell von der Generierung direkt zur Asset-Erstellung übergeht, am Ende ein poliertes Video auf eine URL gerichtet haben kann, die nicht mehr existiert, sobald die Sitzung endet. Der Deploy-Schritt ist das einzige verlässliche Signal, dass die App jetzt eine Adresse hat, die es wert ist, auf einer öffentlichen Seite festgehalten zu werden.