Kann ich mit jemandem zusammenarbeiten? Wege und Grenzen

Kann ich mit jemandem zusammenarbeiten?

Ja, aber über Wege, die schon vorhanden sind, und nicht über gleichzeitiges Bearbeiten desselben Projekts. In der Praxis heißt Zusammenarbeit: die veröffentlichte Adresse zum Ansehen weitergeben, Rückmeldung gebündelt einarbeiten und den Quellcode über GitHub an jemanden übergeben, der weiterbaut.

Das klingt weniger bequem als ein geteilter Arbeitsbereich, funktioniert im Alltag aber erstaunlich gut, weil Website-Projekte in kurzen Runden entstehen. Dieser Text ordnet die vier Dinge, die Menschen mit „zusammenarbeiten“ meinen, und sagt bei jedem, was geht und was nicht.

Was meinen Sie mit Zusammenarbeit?

Vier sehr verschiedene Dinge stecken hinter demselben Wort, und die Lösungen dafür haben nichts miteinander zu tun. Wer den eigenen Fall benennt, spart sich die Suche nach einer Funktion, die er gar nicht braucht.

Die häufigste Lage ist die erste, und sie braucht überhaupt keinen gemeinsamen Zugang. Jemand soll etwas ansehen und etwas dazu sagen. Dafür reicht eine Adresse.

Wie hole ich Rückmeldung ein, ohne Zugang zu geben?

Veröffentlichen und den Link schicken. Jedes veröffentlichte Projekt läuft unter einer Adresse wie unser-entwurf.zugo.run, und die kann jeder öffnen, der sie bekommt. Kein Konto, keine Installation, keine Anleitung.

Bitten Sie um Rückmeldung in einer Liste, nicht in einem Gespräch. Der Grund ist wirtschaftlich: Gesammelte Anmerkungen werden zu einer einzigen Änderung für 3 Credits, einzeln nachgereichte werden zu vier Änderungen für zwölf. Ein geteiltes Dokument mit nummerierten Punkten ist hier mehr wert als jedes Werkzeug.

Praktisch bewährt sich eine feste Frage statt eines offenen „Was meinst du?“. Zum Beispiel: „Welche drei Dinge fehlen dir auf dieser Seite, damit du anfragen würdest?“ Antworten auf diese Frage lassen sich direkt in einen Änderungssatz übersetzen. Antworten auf die offene Frage sind Geschmacksurteile, die sich beim nächsten Ansehen ändern.

Wie bauen zwei Personen an einem Projekt, ohne sich zu stören?

Nacheinander, mit einer klaren Regel darüber, wer gerade dran ist. Das ist kein Notbehelf: Änderungen an einem generierten Projekt wirken auf das ganze Projekt, und zwei gleichzeitige Beschreibungen desselben Bereichs widersprechen sich zwangsläufig.

Drei Absprachen genügen in der Praxis. Erstens: Eine Person führt den Bauauftrag, die andere liefert Inhalte und Anmerkungen. Zweitens: Jede Runde endet mit einer veröffentlichten Fassung, damit alle über dasselbe reden. Drittens: Wer eine Änderung ausgelöst hat, schreibt in einer Zeile mit, was sie bewirken sollte.

Diese Mitschrift ist wertvoller, als sie aussieht. Nach zwanzig Änderungen weiß sonst niemand mehr, warum die Preisliste zweispaltig ist, und man baut die Entscheidung versehentlich zurück. Ein Textdokument mit Datum und Satz reicht dafür völlig.

Wie arbeite ich mit einem Entwickler zusammen?

Über den Export. Der Quellcode lässt sich nach GitHub übergeben, und ab diesem Punkt arbeitet Ihre Entwicklerin mit den Werkzeugen, die sie ohnehin benutzt. Für den Betrieb kann das Projekt auf ein eigenes Vercel-Konto wandern, und Daten sowie Anmeldung liegen ohnehin in Ihrem Supabase-Projekt.

Diese Übergabe ist der Grund, warum ein Builder und ein Entwicklungsteam keine Gegner sind. Der schnelle Teil bleibt schnell: Aufbau, Struktur, Design, die ersten Runden mit dem Kunden. Der teure Teil beginnt erst dort, wo Fachlogik entsteht, die nur Sie brauchen.

Ehrlich gesagt gehört dazu auch die Rückrichtung: Sobald jemand den Code außerhalb weiterentwickelt, ist das Projekt im Builder nicht mehr die aktuelle Fassung. Entscheiden Sie in dem Moment, wo die Wahrheit liegt, und halten Sie sich daran. Was der Export im Einzelnen umfasst, steht in Kann ich den Code exportieren, und die Frage nach dem richtigen Zeitpunkt behandelt Kann ich später einen Entwickler beauftragen.

Was kostet Zusammenarbeit in Credits?

Nichts extra. Bezahlt werden Aktionen, und ob eine Änderung auf Ihre Idee oder auf die Anmerkung Ihres Kunden zurückgeht, ist der Abrechnung gleichgültig.

Die Tarife: Free enthält 5 Credits, Pro kostet 25 $ im Monat mit 200 Credits, Business 99 $ im Monat mit 800 Credits. Zweihundert Credits sind 66 Änderungen oder 33 Builds oder rund 16 mehrseitige Plattformen. Abgerechnet wird in US-Dollar.

Für Projekte mit mehreren Beteiligten ist die Rechnung einfach: Jede Rückmeldungsrunde ist eine Änderung, wenn Sie sammeln, und drei, wenn Sie es nicht tun. Acht Runden gebündelt sind acht Änderungen, also 24. Dieselben acht Runden in Einzelnachrichten sind vierundzwanzig Änderungen und damit das Dreifache.

Wie übergebe ich ein fertiges Projekt an einen Kunden?

In der Reihenfolge Daten, Betrieb, Adresse. Das Supabase-Projekt mit den Inhalten und Konten gehört von Anfang an in das Konto des Kunden, nicht in Ihres, sonst hängt sein Betrieb an Ihrem Zugang. Dasselbe gilt für Stripe, wenn Zahlungen im Spiel sind.

Für den Betrieb gibt es zwei saubere Varianten: Der Kunde übernimmt das Projekt im Builder und ändert selbst weiter, oder Sie exportieren nach GitHub und der Betrieb läuft über sein eigenes Vercel-Konto. Beides ist eine bewusste Entscheidung und sollte im Angebot stehen, nicht nachträglich verhandelt werden.

Zuletzt die Adresse. Solange das Projekt unter entwurf.zugo.run läuft, ist die Übergabe reversibel. Sobald die eigene Domain darauf zeigt, wird sie es nicht mehr, weil ab da echte Besucher darauf landen. Legen Sie deshalb die Domain als letzten Schritt um und nicht als ersten.

Was wird hier ausdrücklich nicht versprochen?

Drei Dinge, damit Sie nicht danach suchen. Erstens gleichzeitiges Bearbeiten desselben Projekts durch zwei Personen, so wie man es aus geteilten Textdokumenten kennt. Zweitens eine Rechteverwaltung im Builder, die einer Person das Ansehen und einer anderen das Ändern erlaubt. Drittens Kommentare, die direkt am Entwurf kleben.

Alles, was in diesem Text steht, kommt ohne diese drei aus. Das ist der ehrliche Zuschnitt: gemeinsam arbeiten über veröffentlichte Fassungen, gesammelte Rückmeldung und Export, nicht über einen geteilten Arbeitsbereich.

Dazu kommt die allgemeine Grenze: Zugo ersetzt bei einem komplexen Produkt kein Entwicklungsteam. Sehr spezifische Fachlogik entsteht über viele Änderungen statt über einen Prompt, und ab einem gewissen Punkt ist ein Mensch, der das System versteht, schneller als jede Beschreibung.

Wie halten wir die Fassungen auseinander?

Über die veröffentlichte Adresse als einzige Wahrheit. Was dort läuft, gilt. Was jemand vor drei Tagen auf einem Bildschirmfoto gesehen hat, gilt nicht. Diese eine Regel verhindert die meisten Missverständnisse in Projekten mit Kunden.

Nützlich ist außerdem eine kurze Runde vor jeder Änderung: Was ist der Zweck, was darf sich dabei nicht verändern? Der zweite Teil wird selten gestellt und ist der wichtigere, weil eine Änderung immer auf das ganze Projekt wirkt und gern etwas mitnimmt, das schon gut war.

Vor der Auslieferung startet Zugo jeden Build in einer Sandbox: Was nicht geladen hat, wird nicht ausgeliefert. Diese Prüfung sagt, dass das Projekt startet, nicht dass es noch das enthält, worauf Sie sich am Montag geeinigt hatten. Ein Blick auf die veröffentlichte Fassung nach jeder Runde bleibt Ihre Aufgabe und dauert zwei Minuten.

Womit fange ich an?

Mit einer veröffentlichten Fassung, bevor Sie überhaupt jemanden fragen. Ein Entwurf, den man anklicken kann, erzeugt brauchbare Rückmeldung. Eine Beschreibung dessen, was entstehen soll, erzeugt Meinungen über etwas, das es noch nicht gibt.

Auf zugo.dev starten Sie mit 5 Credits und 25 Vorlagen, von denen fünf Spiele sind. Eine einfache Seite steht in etwa einer Minute, eine mehrseitige Plattform in einigen Minuten. Schicken Sie die Adresse auf zugo.run herum, sammeln Sie die Punkte in einer Liste und arbeiten Sie sie gebündelt ein. Sobald sich alle einig sind, legen Sie die eigene Domain darauf: Wie das geht, steht in KI-App-Builder mit eigener Domain.

Zusammenarbeit scheitert selten an fehlenden Funktionen. Sie scheitert an Rückmeldung, die nirgends aufgeschrieben wurde.