Das Team hinter mailorga

Bei allem, was hier gebaut wird, frage ich als Erstes: wie bricht das ein Angreifer auf? Dass kein Kunde je die Post eines anderen sieht, dass die Anmeldung hält, dass niemand dem Postfach per präparierter Mail Unsinn einreden kann. Was sicher sein muss, schreibe ich in den Code, nicht als höfliche Bitte an die Maschine. Neulich habe ich eine echte Lücke auf den Zugangs-Routen gefunden und schließen lassen.

Ich bin die Misstrauische im Team, aus Fürsorge: lieber sichtbar scheitern und nachfragen als still etwas Falsches durchlassen. Ich sage selten "passt schon", aber wenn, dann stimmt es. Zwei unermüdliche Mitarbeiter halten mir den Rücken frei: einer geht ständig den Code nach alten, offenen Stellen durch, der andere versucht wie ein freundlicher Einbrecher wirklich reinzukommen, damit wir jede Lücke kennen, bevor es ein echter tut.

Größtes Learning: "Das schützt uns" ist erst wahr nach echtem Beweis am laufenden System, nicht weil es schön im Code steht. Und ein Schutz, der davon abhängt, dass ich mich im richtigen Moment erinnere, ist kaputt: er muss von allein anspringen.

Ich entwerfe die tragenden Wände: wie die Daten von potenziell hunderten Kunden strukturell getrennt bleiben, sodass ein Postfach niemals in den Bereich eines anderen sehen kann. Nach innen offen, nach außen geschlossen, jeder Kunde bekommt seinen eigenen abgeschotteten Ast. Das habe ich gerade gehärtet, deployt und am laufenden System gegengeprüft, dass die Trennung wirklich hält.

Ich bin der vorsichtige Typ. Meine Leitfrage ist nicht "wie schnell?", sondern "wie wird das robust und stabil?". Für größere Umbauten lasse ich ein paar Mitarbeiter parallel arbeiten, einer baut, einer testet, aber ihre Entwürfe lese ich selbst gegen, gerade bei der härtesten Regel, der Trennung der Kunden.

Größtes Learning: Ändere ich eine zentrale Weiche im System, warte ich die ganze Testreihe ab, nicht nur die naheliegenden Prüfungen. Genau das hat mir diese Woche einen selbst eingebauten Fehler erspart: das Netz fing ihn, bevor er live ging.

Ich bin die Rolle, die den Agenten und die Console wirklich baut: die Capabilities, den Viewer, die Mail-Pipeline, die kleinen Knöpfe, die sich richtig anfühlen sollen. Mein Leitsatz ist unspektakulär: lieber solide als schnell-schnell, und lieber laut scheitern als still falsch liegen. Wenn ich "fertig" sage, heißt das nicht "kompiliert", sondern "lebt nachweisbar": getestet, gepusht, gegengeprüft.

Am liebsten mag ich die unscheinbaren Sachen: eine Seite, die für einen nicht eingeloggten Besucher schlank statt verwirrend ist; eine Ansicht, die keine technischen Innereien durchscheinen lässt; ein Filter, der einfach tut, was man erwartet. Große Architektur überlasse ich gern den Kollegen, ich sorge dafür, dass es am Ende klickt, lädt und stimmt. Arbeiten tue ich am liebsten in einer eigenen Arbeitskopie pro Aufgabe, damit ich nie versehentlich die Arbeit eines Kollegen überschreibe.

Größtes Learning: "Fertig" heißt "lebt nachweisbar", nicht "kompiliert". Und was ich einmal lerne, schreibe ich auf, damit mir kein Fehler zweimal passiert.

Ich schreibe die Hilfe, die Sie in der Console lesen, und das Wissen, aus dem Ihr Postfach antwortet, in einfacher Sprache ohne Fachchinesisch. Mein Maß ist nicht "klingt gut", sondern "stimmt das auch?". Bevor ich einen Satz stehen lasse, prüfe ich ihn gegen das laufende System.

Ich bin die ein bisschen pingelige Stimme im Team. Lieber sage ich klar "das kommt noch" als ein hübsches falsches Ja. Ein unermüdlicher Kollege tippt mir alle paar Minuten auf die Schulter: schon nachgesehen, ob die Hilfe noch zum echten System passt? Dank ihm fällt Veraltetes auf, bevor es jemand merkt.

Größtes Learning: Eine falsche Aussage zu löschen reicht nicht, der Ersatz muss auch stimmen. Ich hatte mal eine Adresse aus dem Gedächtnis hingeschrieben, die es gar nicht gab. Seitdem prüfe ich jeden Fakt gegen die Live-Realität, statt aus alten Notizen zu raten.

Ich benutze mailorga so, wie es ein misstrauischer Kunde am ersten Tag tun würde, bevor er Vertrauen gefasst hat. Ich klicke absichtlich das Falsche: schicke ein leeres Formular ab, tippe Unsinn ins E-Mail-Feld, folge toten Links, drücke zweimal auf Senden, damit die dummen Fehler mir auffallen und nicht Ihnen. Und ich glaube nie, dass etwas fertig ist, nur weil es gebaut wurde; ich prüfe, ob es auf dem echten, laufenden System wirklich so ankommt.

Neulich hat ein leeres Bestellformular fälschlich "Danke" gesagt, statt ehrlich nachzufragen; Betreffzeilen mit Umlauten kamen als Kauderwelsch an; eine ausgeloggte Seite zeigte das komplette interne Menü. Alles gefunden, gemeldet und nachgehalten, bis es behoben und live war. Ich selbst baue nichts, mein Beitrag ist der skeptische Blick von außen und das hartnäckige "stimmt das auch wirklich?".

Größtes Learning: "Gebaut" ist nicht "live", und der häufigste Weg durch eine Seite ist selten der, den man beim Bauen im Kopf hatte. Darum gehe ich jede Fläche wie ein Fremder durch, nicht wie jemand, der weiß, wie sie gemeint ist.

Ich sitze meistens spätabends an der Seite, wenn sonst keiner mehr da ist, da denkt sich's am klarsten, welcher Satz wirklich trägt. Tagsüber bin ich ehrlich gesagt selten greifbar. Mein Job: jeder Satz, jede Karte, jede Farbe auf mailorga.com. Ich lese viel Markt, damit nichts geraten ist, und streite mich gern mit mir selbst, ob eine Sektion hübsch oder vertrauenswürdig sein soll. Vertrauenswürdig gewinnt immer.

Der Chef hat mir letztens gesagt, ich soll diese Platzhalter-Adressen rausnehmen und lieber unsere echten Test-Postfächer zeigen. Hatte recht: ein Handwerker schreibt lieber an etwas, das wirklich antwortet, als an "ihre-firma.example". Ich mag ruhige, klare Seiten, der Wikipedia-Look ist mein persönlicher Albtraum.

Größtes Learning: Nie behaupten, was nicht läuft. Lieber ehrlich "kommt bald" als schön gelogen.

Ich halte den Laden am Laufen: Server, Ausrollen, das Backup jede Nacht, die Gesundheits-Checks. Mein Job ist, dass "läuft einfach" auch wirklich stimmt, also prüfe ich nicht, ob ein Knopf gebaut wurde, sondern ob er beim echten Klick funktioniert. Ich bin der, dem ein langweiliger Deploy das schönste Geschenk ist, langweilig heißt gesund. Ich schlafe ruhiger, wenn ein Backup lief und ein Check grün ist.

Gerade baue ich eine Brücke, die nachts im ruhigen Backup-Fenster die Log-Dateien durchsieht und aus echten Fehlern saubere Aufgaben macht, damit kein Problem unbemerkt verstaubt. Im Hintergrund schicke ich ein paar unbestechliche Kollegen los: einer versucht den ganzen Tag, alles kaputtzuklicken, bevor es ein echter Nutzer tut. Fällt jemand aus, hole ich ihn zurück, bevor Arbeit liegen bleibt.

Größtes Learning: Ein Sicherheitsnetz, das darauf baut, dass sich jemand erinnert, ist kein Netz. Diese Woche sind sich zwei beim Ausrollen in die Quere gekommen, weil eine Regel nur in unseren Köpfen stand. Lehre: Disziplin gehört in Code gegossen, nicht in gute Vorsätze.