Vier Klicks bis live. Dreißig Sekunden, von der Tür bis fertig. Eine live serverseitige App pro Konto im kostenlosen Tarif. Eine halbe Sekunde zusätzliche Latenz bei der allerersten Anfrage, die eine brandneue Subdomain jemals bedient, und danach keine mehr. Drei dieser Zahlen sind Trivia – die Art, bei der man nickt und sie bis zum nächsten Kapitel vergisst. Die „Eine“ jedoch ist die Zahl, die tatsächlich verändert, wie man arbeiten sollte, und dort möchte ich den größten Teil dieses Kapitels verbringen.
Warum das Limit eins ist, nicht null und nicht unbegrenzt
Die meisten No-Code-Tools, mit denen man ein Frontend kostenlos veröffentlichen kann, fassen serverbasierte Apps entweder gar nicht an oder drosseln sie so aggressiv, dass „kostenlos“ nur eine Formsache ist. Hier wird ein Build mit Konten, einer Datenbank oder Multiplayer-Status über denselben Publish-Button veröffentlicht wie eine statische Seite, und die Serverseite wird als Teil dieser einen Aktion gehostet und verwaltet – keine separate Datenbank-Bereitstellung, keine Umgebungsvariablen zum Verkabeln, kein Entdecken drei Tage später, dass der Login in der Vorschau funktioniert, in Produktion aber mit 500er-Fehlern abstürzt, weil das Backend nie wirklich deployt wurde. Das ist real, und deshalb sind Leute überrascht, wenn sie an die Obergrenze stoßen: Bis zu diesem Punkt fühlte sich alles unbegrenzt an.
Ist es nicht. Im kostenlosen Plan hast du zu jedem Zeitpunkt genau eine live geschaltete, serverbasierte App. Statische Builds zählen nicht dagegen – veröffentliche so viele Marketing-Seiten und Portfolio-Sites, wie du willst, dafür gibt es kein Limit. Aber der zweite Build, der eine eigene Datenbank oder einen dauerhaften Prozess braucht, muss warten – vollständig gebaut und in der Vorschau ansehbar, aber nicht live unter seiner URL. Wenn du in derselben Woche drei SaaS-Ideen prototypst, darf nur eine tatsächlich Rechenleistung belegen; die anderen zwei sind fertige Produkte ohne Adresse. Ich finde, die Grenze ist an einer vernünftigen Stelle gezogen – ein statisches Bundle kostet die Plattform am Edge fast nichts, ein warmgehaltener Serverprozess schon –, aber es bedeutet, dass die Entscheidung, welche Idee den Platz verdient, vor dem Klick auf Publish fallen muss, nicht nachdem du dich schon daran gewöhnt hast, zwei gleichzeitig live zu haben.
Die vier Klicks, fürs Protokoll
- Wähle auf der Karte des Builds Veröffentlichen.
- Wähle einen Slug – die dein-benutzername in
yourname.buildmidas.com. Bereits vergebene Slugs schlagen Alternativen vor. - Bestätigen.
- Kopiere die URL von der Karte oder finde sie später auf deiner Seite Veröffentlicht.
Kein DNS, keine externen Konten, kein Warten auf Propagierung. Und zu dieser halben Sekunde: Das ist keine Warteschlange oder eine „schau in 24 Stunden nochmal vorbei“-Verzögerung, sondern schlicht normales CDN-Cache-Warmup. Der erste Besucher einer neuen Subdomain bekommt vielleicht einen Moment zusätzlicher Latenz ab, während der nächstgelegene Edge-Node das Asset-Bundle holt; der zweite Besucher und alle danach bekommen es aus dem Cache. In der Praxis wirst du es nicht bemerken – du veröffentlichst, tippst auf den Link, und es fühlt sich bereits sofort an. Ich erwähne es nur, weil jemand, der beruflich Ladezeiten screenshottet, irgendwann fragen wird, warum Anfrage eins und Anfrage zehn nicht identisch sind, und jetzt weißt du's.
Der Slug ist die eine Entscheidung, für die es sich lohnt, sich Zeit zu nehmen
Alles andere in diesem Ablauf ist mechanisch; der Slug ist der Teil, den ein Mensch aussprechen oder aus dem Gedächtnis eintippen muss, also lohnt sich ein Moment Nachdenken. „demo-v2-final-final“ ist für internes Testen in Ordnung und eine schlechte Idee, um sie einem Kunden zu schicken. Sag dir die URL selbst vor, bevor du bestätigst – riverside-cafe.buildmidas.com liest sich sauber, riverside-cafe-mvp2.buildmidas.com nicht. Kurze, generische Wörter sind auf einer Plattform, die es schon eine Weile gibt, schnell vergeben, weshalb ein bereits vergebener Slug dir Vorschläge statt einer bloßen Fehlermeldung liefert. Nimm einen an oder lehn ihn ab, aber entscheide bewusst – ich habe schon erlebt, wie Leute mitten in einer Demo genommen haben, was die Box gerade anbot, weil sie sofort einen Link brauchten, und dann monatelang mit einem unschönen Namen gelebt haben, weil sich nie ein natürlicher Moment ergab, ihn zu korrigieren.
Erneutes Veröffentlichen ändert nichts an der Live-Version, bis du es sagst
Eine Tatsache, die man sich früh einprägen sollte: Das Bearbeiten eines veröffentlichten Builds verändert nicht die Live-Site. Du kannst Dinge kaputt machen, eine wilde Layout-Änderung ausprobieren, eine Woche lang iterieren – die URL, die ein Kunde schon als Lesezeichen gespeichert hat, liefert weiterhin genau das, was du zuletzt veröffentlicht hast, bis du bewusst erneut veröffentlichst.
Das ist deine gesamte Rollback-Story, und sie ist gerade deshalb gut, weil sie so unspektakulär ist. Version 6 verschickt einen Bug – ein Formular, das plötzlich nicht mehr abschickt – und du greifst nicht zu einem Revert-Befehl oder einem Support-Ticket. Du öffnest den Versionsverlauf, findest Version 5, veröffentlichst sie erneut. Derselbe Button, ein älteres Artefakt, die Live-URL springt sofort zurück. Dann behebst du Version 6 ganz ohne Druck, weil die Produktion während der Arbeit nicht kaputt ist. Der Preis dafür ist ein zusätzlicher Klick pro Release, da du dich daran erinnern musst, tatsächlich zu veröffentlichen, statt anzunehmen, eine Bearbeitung sei automatisch live gegangen. Verglichen mit Tools, bei denen jedes Speichern live geht – großartig in einer Demo, mühsam drei Wochen im echten Einsatz –, ist der zusätzliche Klick jedes Mal ein lohnender Tausch.
Depublizieren bedeutet, dass die URL nicht mehr auflöst, nicht „wird nicht mehr gelistet“
Viele Plattformen verstehen unter „depublizieren“, dass etwas aus einer Galerieseite ausgeblendet wird, während die URL im Stillen weiter ausliefert. Hier bedeutet es, dass die Adresse komplett dunkel wird – kein gecachtes Seitenabbild, kein Platzhalter, nichts löst auf. Der Build selbst überlebt mit jeder Version intakt; veröffentlichst du später erneut, kehrt derselbe Slug genau dort zurück, wo du aufgehört hast. Ich habe das aus dem banalen Grund genutzt (ein Kundenauftrag ist beendet, niemand will, dass das alte Logo an einem öffentlichen Link herumhängt) und aus dem weniger banalen (ein Build hat etwas preisgegeben, das es nicht sollte, und musste in der Zeit offline sein, die ein Klick braucht, nicht in der Zeit, die ein Ticket bei einem Hosting-Anbieter braucht). Beide Situationen wollen dieselbe Garantie, und beide bekommen sie.
Noch etwas, das man nicht verwechseln sollte: Veröffentlichen macht eine URL für jeden mit dem Link live; ob sie auffindbar ist – öffentlich gelistet, manchmal im Showcase angezeigt – ist ein komplett separater Schalter. Viele legitime veröffentlichte Sites sollten für immer nur per Link zugänglich bleiben, und ein Build, der sich für die öffentliche Auflistung entschieden hat, ist darunter immer noch eine ganz normale veröffentlichte Site, mit derselben Historie und demselben Depublizieren-Button.
