Bauen, dann betreiben.

In den meisten Agenturprojekten gibt es einen Moment, in dem die Arbeit den Besitzer wechselt. Die letzte Rechnung ist bezahlt, ein Repository wird übertragen, jemand wird zu einem Hosting-Konto hinzugefügt, und die Menschen, die jede Entscheidung getroffen haben, gehen den Konsequenzen all dieser Entscheidungen aus dem Weg. Wir standen auf beiden Seiten dieser Übergabe. Das ist der Grund, warum wir damit aufgehört haben.

Synodic baut Produkte und betreibt sie anschließend. Nicht als Support-Vertrag, der am Ende angeschraubt wird, sondern als Annahme, von der das Projekt ausgeht: Was immer wir ausliefern, wir sind diejenigen, die dafür wach sind.

Ausgeliefert ist nicht dasselbe wie im Betrieb

Ein Launch ist ein einzelner Tag. Betrieb sind die achtzehn Monate danach, und dort zeigen sich die tatsächlichen Kosten einer Entscheidung. Eine Abhängigkeit wird nicht mehr gepflegt. Traffic kommt in einer Form, die niemand modelliert hat. Eine Drittanbieter-API ändert an einem Freitagnachmittag ein Antwortformat. Nichts davon ist in einem Design-Review sichtbar, und alles davon ist um drei Uhr morgens sichtbar.

Wenn das Team, das den Code geschrieben hat, auch das Team ist, das den Alarm bekommt, hören diese Ausfälle auf, das Problem von jemand anderem zu sein, das man dokumentiert, und werden zum eigenen Wochenende. Das ist eine bemerkenswert wirksame Design-Einschränkung.

Was sich vor dem Launch ändert

Zu wissen, dass wir etwas betreiben werden, lässt uns anders bauen, und fast immer schlichter. Raffinesse ist teuer, wenn man selbst die Wartung dafür bezahlt.

• Jede Stack-Entscheidung ist eine, die wir selbst in Produktion betrieben haben. Wir haben kein Interesse daran, zum ersten Mal auf dem Traffic eines Kunden herauszufinden, was eine Datenbank unter Last tut.
• Monitoring und Alarmierung kommen vor dem ersten echten Nutzer, nicht nach dem ersten Ausfall. Wenn wir ein System nicht sehen können, gilt es für uns nicht als gelauncht.
• Weniger bewegliche Teile schlagen eine elegantere Architektur. Jeder Dienst, den wir hinzufügen, ist eine weitere Sache, die um drei Uhr morgens ausfallen kann.
• Wenn ein Feature nur von der Person erklärt werden kann, die es geschrieben hat, ist es nicht fertig. Code, der nicht an die Person mit Bereitschaft übergeben werden kann, ist ein Risiko mit hübscher Oberfläche.

Produktion ist das Design-Review. Alles davor ist eine Probe.

Der Tausch

Dieses Modell skaliert nicht so, wie eine Agentur es sollte. Wir übernehmen wenige Projekte gleichzeitig, bleiben jahrelang dabei und sagen weit öfter Nein als Ja, meist weil wir nicht verantwortungsvoll noch ein Produkt zu denen hinzufügen können, die wir bereits am Leben halten.

Was Sie dafür bekommen, ist ein Studio ohne Anreiz, etwas halbfertig liegen zu lassen. Es gibt keinen Punkt, an dem sich unsere Interessen und Ihre trennen, denn das, was wir gebaut haben, ist das, womit wir leben müssen.

Arbeiten Sie an etwas, das passt? Erzählen Sie uns davon.