KI-App-Builder mit GitHub: Quellcode selbst exportieren

KI-App-Builder mit GitHub: Quellcode selbst exportieren

Ja, der Quellcode geht in Ihr eigenes GitHub-Repository. Der Export ist eine eingebaute Anbindung und kein Umweg: Was Sie in Zugo bauen, gehört Ihnen vollständig, und jeder Entwickler öffnet das Ergebnis danach in einem gewöhnlichen Editor. Das ist die Antwort auf die Frage, was bleibt, wenn Sie die Plattform verlassen.

Der Rest dieses Textes klärt vier Dinge: warum sich der Export lohnt, was genau im Repository liegt, was er kostet und woran Sie merken, dass der Moment für eine Übergabe gekommen ist.

Wozu Quellen exportieren, wenn das Projekt längst läuft?

Solange das Projekt im Builder liegt und per Satz geändert wird, wirkt der Export wie ein Schritt, den man überspringen kann. Wichtig wird er in drei Situationen, und keine davon tritt am ersten Tag ein.

Die erste: Ein Entwickler kommt dazu. Sehr spezifische Fachlogik schreibt sich schneller von Hand, als sie sich in Worten beschreiben lässt. Ein Entwickler möchte ein Repository und keinen Zugang zu einer fremden Oberfläche, und mit einem exportierten Projekt fängt er sofort an.

Die zweite: Sie wollen eine Sicherung, die an keinem einzelnen Dienst hängt. Ein Repository im eigenen Konto ist eine Kopie, die auch dann bestehen bleibt, wenn ein Abonnement ausläuft oder eine Rechnung im Spam-Ordner untergeht.

Die dritte: Das Projekt wächst über den Builder hinaus. Zugo ersetzt bei einem komplexen Produkt kein Entwicklungsteam, und das rechtzeitig zuzugeben ist billiger, als ein Jahr lang Änderungen in etwas hineinzuzwingen, das anders gebaut gehört. Der Export macht aus diesem Übergang eine Fortsetzung der Arbeit statt eines Neuanfangs.

Was landet im Repository, und was bleibt draußen?

Im Repository liegt, woraus das Projekt besteht: die Dateien der Oberfläche, die Stile, die Build-Konfiguration und die Liste der Abhängigkeiten. Also ein Quellprojekt, das man öffnen, lesen und ändern kann, und keine abgespeicherte Kopie einer fertigen Seite.

Genauso nützlich ist zu wissen, was dort nicht liegt. Ihre Daten nicht, sofern das Projekt sie in einer externen Datenbank hält: Tabelleninhalte leben in Supabase und nicht im Code. Zugangsschlüssel von Zahlungs- oder Maildiensten nicht, denn Geheimnisse gehören nicht in ein Repository. Und die Plattform selbst nicht: Sie nehmen Ihr Projekt mit, nicht den Motor, der es zusammengesetzt hat.

Diese Aufteilung ist Absicht und entspricht der üblichen Praxis: Code ins Repository, Daten in die Datenbank, Schlüssel in Umgebungsvariablen. Ein so exportiertes Projekt muss nicht erst umgeräumt werden, bevor es eigenständig laufen kann. Die breitere Fassung dieser Frage, samt Zugängen und veröffentlichter Adresse, steht in Kann ich den Code exportieren.

Wie sieht der Weg vom Satz zum Repository aus?

Die Schritte eins bis drei dauern Minuten: Ein einfacher Build steht in etwa einer Minute, eine mehrseitige Plattform in einigen Minuten. Ab Schritt vier ist es gewöhnliche Entwicklung, und die Dauer hängt an der Aufgabe, nicht am Builder.

Die Reihenfolge muss nicht linear sein. Viele exportieren einmal zur Absicherung, arbeiten danach weiter im Builder und kehren ein halbes Jahr später ins Repository zurück. Das ist ein normales Muster, denn ein Export schaltet auf der Zugo-Seite nichts ab.

Was habe ich von einem Repository, wenn ich nicht programmiere?

Für eine Projektinhaberin, die keinen Code schreibt, sieht ein Repository zunächst nutzlos aus. In der Praxis gibt es vier Dinge, die auch ohne Editor etwas bringen.

Sie sehen, dass der Code existiert und Ihnen gehört. Repository im Browser öffnen, Dateiliste ansehen, fertig. Das genügt, um zu verstehen, dass hinter dem Projekt eine echte Sache steht und nicht ein Bild in einem fremden Dienst.

Sie geben einem Dienstleister Zugriff, ohne Ihre Passwörter herauszugeben. Rechte am Repository werden getrennt vergeben und nach Abschluss der Arbeit mit einem Klick wieder entzogen. Das ist deutlich sicherer, als Zugangsdaten zum Arbeitsbereich weiterzureichen.

Sie sehen die Historie der Änderungen. Jede Aktualisierung liegt als eigener Eintrag vor, also ist immer nachvollziehbar, was wann geändert wurde. Bei Meinungsverschiedenheiten mit einem Auftragnehmer klärt die Historie die Frage schneller als der E-Mail-Verlauf.

Sie schlafen ruhiger. Ein Repository überlebt ein gekündigtes Konto, ein vergessenes Abonnement und jede Störung auf Plattformseite.

Worin unterscheidet sich der Export von einem Deployment bei Vercel?

Diese beiden Anbindungen lösen verschiedene Aufgaben und werden ständig verwechselt.

Eine sinnvolle Kombination sieht so aus: GitHub macht den Code zu Ihrem, Vercel macht die Auslieferung zu Ihrer, Supabase macht die Daten zu Ihren. Zusammen wird das Projekt von jedem Abonnement unabhängig, auch von dem bei Zugo. Wie die Hosting-Hälfte funktioniert, steht in KI-App-Builder mit Vercel.

Was kostet der Export?

Der Export selbst verbraucht keine Credits. Credits gehen für Generierung weg, und die Preise dafür sind überschaubar.

Die Tarife sind ebenso schlicht. Free gibt Ihnen 5 Credits, Pro kostet 25 $ im Monat und enthält 200 Credits, Business kostet 99 $ im Monat und enthält 800. Zweihundert Credits reichen, jeweils für eine einzige Art von Aktion gerechnet, für rund 16 vollständige Plattformen oder 33 Builds oder 66 Änderungen.

Eine Rechnung lohnt sich vor der Anmeldung: 5 Credits sind weniger als die 6, die ein einzelner Build kostet. Der kostenlose Tarif ist ein Rundgang durch die Oberfläche und kein fertiges Projekt. Abgerechnet wird in US-Dollar.

Für die Exportfrage ist daran ein Punkt wesentlich. Teuer ist das Erzeugen des Projekts, nicht das Herausholen. Würde für den Zugriff auf den eigenen Code eine eigene, mit der Zeit steigende Gebühr fällig, wäre die Aussage über das Eigentum Dekoration und keine Tatsache.

Wann ist der Moment für einen Entwickler gekommen?

Vier Anzeichen sagen, dass die Übergabe ansteht.

Dieselbe Änderung scheitert zum dritten Mal. Wenn Sie eine Anforderung dreimal umformuliert haben und das Ergebnis weiter danebenliegt, ist die Anforderung komplexer, als eine Beschreibung sie tragen kann. Der vierte Versuch wird nicht billiger.

Die Logik hängt an einem fremden System. Preise aus einem Warenwirtschaftssystem, Austausch mit der Buchhaltung, ein ungewöhnliches Exportformat für den Steuerberater: Das ist Arbeit gegen eine konkrete fremde Schnittstelle und kein Standardfall.

Es kommen Anforderungen auf, die man nicht ansehen kann. Last, Antwortzeiten bei vielen gleichzeitigen Nutzern, Rechtegrenzen innerhalb einer Organisation. So etwas prüft man mit Werkzeugen und Erfahrung, nicht mit den Augen.

Ausfallzeit kostet Geld. Sobald ein stehendes Projekt am selben Tag Umsatz kostet, braucht es einen Verantwortlichen und nicht nur einen bequemen Editor. Wie eine solche Übergabe praktisch abläuft, steht in Kann ich später einen Entwickler beauftragen.

Wo liegen die Grenzen dieser Kombination?

Drei Dinge gehören klar gesagt.

Exportierter Code ist kein schlüsselfertiges Produkt. Er öffnet sich, er liest sich, er ändert sich, aber sein weiteres Leben braucht dasselbe wie jedes andere Repository: Builds, Deployments, Aktualisierungen der Abhängigkeiten. Wenn niemand das übernimmt, löst der Export allein nichts.

Der Export nimmt die Arbeitsweise der Plattform nicht mit. Änderungen per Satz gibt es in Zugo. Im Repository ändern Sie Code von Hand, und das ist eine andere Fertigkeit. Viele arbeiten genau deshalb weiter im Builder und halten das Repository als Versicherung.

Ein einmaliger Export veraltet. Arbeiten Sie danach in Zugo weiter, zeigt das Repository den Stand vom Tag des Exports. Frischen Sie ihn auf, wenn tatsächlich eine Übergabe ansteht.

Und eine Erwartung gehört noch gerade gerückt: Jeder Build läuft vor der Übergabe in einer Sandbox, und was nicht geladen hat, wird nicht ausgeliefert. Das senkt die Wahrscheinlichkeit, etwas Kaputtes zu bekommen. Über Architektur, Testabdeckung oder das Urteil eines erfahrenen Entwicklers sagt es nichts. Spiele entstehen zudem als 2D-Spiele im Browser, was eine Festlegung des Produkts ist und kein Mangel, den ein Export behebt.

Womit fange ich am besten an?

Bauen, ändern, bis es passt, exportieren, und das Repository wenigstens einmal öffnen. Den eigenen Quellcode zu sehen überzeugt mehr als jeder Text darüber.

Fangen Sie klein an. Eine einseitige Website, an einem Abend gebaut und exportiert, erklärt das Zusammenspiel besser als eine Anleitung. Es gibt 25 Vorlagen, davon 5 für Spiele, falls Sie nicht vor einem leeren Feld sitzen möchten. Die ganze Kette von der Beschreibung bis zum Repository können Sie auf zugo.dev durchgehen.