Irgendwann im ersten Gespräch kommt die Frage, meistens ein bisschen vorsichtig: "Und ihr seid... zu zweit?" Dahinter steckt eine echte Sorge, und sie ist berechtigt. Du gibst ein Vorhaben in die Hände von zwei Leuten, von denen einer krank werden, ausfallen oder irgendwann woanders sein kann. Darüber lohnt es sich ehrlich zu reden, statt die Frage mit einem Spruch wegzuwischen.

Ja, wir sind zu zweit. Jule und ich. Das ist kein Detail, das wir verstecken, sondern eine Entscheidung. Aber die ehrliche Frage hinter deiner ist nicht "seid ihr zwei", sondern "trägt das mein Projekt, auch wenn mal etwas schiefgeht". Das ist eine andere Frage, und sie verdient eine andere Antwort als ein Werbeslogan.

Die Frage hinter der Frage

Eigentlich stecken zwei Sorgen drin, und sie zeigen in verschiedene Richtungen. Die eine ist die Kapazität: Schaffen zwei Leute das überhaupt, oder liege ich hinten in einer Warteschlange, während ihr an etwas anderem baut? Die andere ist das Risiko: Was, wenn einer von euch wegfällt, hängt dann mein ganzes Projekt an einer einzigen Person, die gerade nicht da ist?

Beide Sorgen sind berechtigt. Und beide haben eine konkrete Antwort, keine beruhigende. Fangen wir mit der Kapazität an.

Warum zwei heute mehr bauen als zwei vor zehn Jahren

Ein kleines Team klingt nach wenig. Vor zehn Jahren wäre es das auch gewesen. Heute verschiebt sich, was zwei Leute leisten, und das liegt nicht an Heldentum, sondern an der Art, wie wir arbeiten.

Der grösste Teil der Arbeit in einem Softwareprojekt ist Routine. Immer wiederkehrende Muster, Code, der sich ähnelt, Tests, die geschrieben werden wollen. Genau diesen Teil übernehmen bei uns KI-Agenten unter unserer Führung. Das Ergebnis ist nicht, dass wir weniger arbeiten. Es ist, dass unsere Stunden dort landen, wo wirklich ein Kopf gebraucht wird: bei den Entscheidungen, der Architektur, dem Blick darauf, ob das Gebaute auch das Richtige ist.

Wie weit das trägt, haben wir bei einem MVP in sechs Wochen aufgeschrieben. Das war kein Einzelfall mit doppelten Nächten, sondern unser normaler Rhythmus. Zwei Leute, die den langweiligen Teil delegieren, kommen heute dorthin, wofür es früher ein halbes Team brauchte.

Was, wenn einer von euch ausfällt?

Jetzt die unangenehmere Frage, und die ehrliche Antwort darauf. Ja, einer von uns kann krank werden oder zwei Wochen in den Ferien sein. Der Unterschied ist, was dann passiert.

Wir predigen in Projekten, dass Wissen nicht in einem einzigen Kopf stecken darf. Es wäre schräg, uns selber davon auszunehmen. Also halten wir uns daran: Beide kennen das ganze Projekt. Code, Entscheidungen, Zugänge, das Warum hinter den Dingen, alles ist geteilt und dokumentiert, nicht nur in einem von uns. Wenn ich zwei Wochen weg bin, macht Jule weiter, und umgekehrt. Nicht reibungslos wie ein Uhrwerk, aber ohne Stillstand.

Und jetzt die Seite, die in der Frage selten mitgedacht wird. Beim grossen Anbieter ist dein Projekt eines von vierzig. Es wird dem zugeteilt, der gerade frei ist. Die eine Person, die es wirklich verstanden hat, hat letzten Monat gekündigt, und niemand hat es dir gesagt. Viele Namen auf einer Webseite heissen nicht, dass auch nur einer davon dein Projekt im Kopf hat.

Von dir zu dem, der es baut. Ohne Zwischenstation

Von dir zu dem, der es baut. Ohne Zwischenstation

Bei einem kleinen Studio redest du mit der Person, die den Code schreibt. Kein Projektmanager, der deinen Wunsch halb verstanden an einen Entwickler weitergibt, den du nie zu Gesicht bekommst. Was du sagst, kommt direkt dort an, wo es gebaut wird. Das klingt nach einer Kleinigkeit und ist in Wahrheit der Grund, warum am Ende das Richtige entsteht und nicht das, was durch drei Ohren gewandert ist.

Der Vorteil, den du bei den Grossen nicht kriegst

Direkter Kontakt ist das eine. Das andere ist Fokus. Wir nehmen bewusst wenige Projekte an, manchmal sagen wir auch Nein, gerade weil wir zu zweit sind. Das heisst: Dein Projekt ist bei uns nicht eine Nummer unter vielen, sondern eines von wenigen, das wir beide im Kopf haben.

Dazu kommt die Nähe. Wir sitzen in Bern, in deiner Zeitzone, in deiner Sprache. Eine Frage am Vormittag hat am Nachmittag eine Antwort, und zwar von jemandem, der weiss, wovon er redet, nicht von einem Ticketsystem.

Zwei Leute, die dein Projekt ganz kennen, sind kein Risiko gegenüber zwanzig, von denen keiner es ganz kennt. Oft ist es genau umgekehrt.

Wann zwei wirklich nicht reicht

Jetzt die faire andere Seite, denn sonst klingt das, als wären wir für alles die Antwort. Sind wir nicht. Es gibt Vorhaben, für die ein Zweierteam der falsche Partner ist, und dann sagen wir dir das.

Wenn du eine Software brauchst, die rund um die Uhr jemanden am Pikett hat, der bei einem Ausfall um drei Uhr nachts aufsteht, sind wir nicht die Richtigen. Wenn an deinem Projekt fünf Teams parallel bauen müssten, um den Termin zu halten, auch nicht. Dann ist ehrlicherweise ein grösserer Anbieter die bessere Wahl, und wir helfen dir eher, das einzuordnen, als dir etwas zu verkaufen, das wir nicht halten können.

Und die Frage, die hinter allem lauert: Was, wenn ihr beide verschwindet? Dafür gibt es eine klare Antwort, und sie hat nichts mit Vertrauen zu tun, sondern mit Handwerk. Der Code und das Wissen gehören dir, sauber dokumentiert und so gebaut, dass auch ein anderes Team weitermachen kann. Du sitzt nie auf etwas fest, das nur wir verstehen. Genau das ist der Unterschied zwischen "zu zweit" und "abhängig".

Die Faustregel

Frag nicht, wie viele Leute an deinem Projekt arbeiten. Frag, wie viele es wirklich ganz verstehen, und was passiert, wenn einer davon morgen fehlt. Bei dieser Antwort trennt sich das kleine Team, das dich trägt, vom grossen, in dem dein Projekt bloss mitläuft.

Am Ende geht es nicht um die Zahl auf der Teamseite. Es geht darum, ob die Leute, die dein Projekt bauen, es auch im Kopf haben, erreichbar sind und dir ehrlich sagen, wann sie die Richtigen sind und wann nicht. Zwei können das. Zwanzig manchmal nicht. Und falls wir für dein Vorhaben die Falschen sind, erfährst du das von uns zuerst.

Du fragst dich, ob zwei Leute dein Projekt stemmen? Erzähl uns, was du vorhast, wir sagen dir ehrlich, ob wir die Richtigen dafür sind.

#Zusammenarbeit#Aus Bern#KMU#Ohne Bullshit
Marco

Marco

Co-Founder & Lead Engineer · FlowCode Bern. Schreibt über das, was beim Bauen wirklich passiert.