Nuri für die Tage bauen, an denen etwas kaputtgeht

Diese zwei Wochen liefen nicht nach Plan

Wir hatten einen Plan für die vergangenen zwei Wochen. Dann kamen diese zwei Wochen.

Wir wollten die Zeit nutzen, um an der App zu feilen, mit der Distribution anzufangen und mehr Nutzer zu Nuri zu holen. Stattdessen verbrachten wir einen großen Teil davon damit, auf Probleme bei Bitcoin, Lightning und verschiedenen Zahlungswegen zu reagieren.

Ehrlich gesagt war es anstrengend.

Nicht weil jedes Problem katastrophal gewesen wäre. Wir stehen noch am Anfang, und die Zahl der betroffenen Nutzer war überschaubar. Aber es fühlte sich an wie in „Und täglich grüßt das Murmeltier“: Kaum hatten wir ein Teil repariert, änderte sich ein anderes. Dann funktionierte ein Fallback nicht mehr, dann brauchte noch etwas anderes unsere Aufmerksamkeit.

Meine erste Reaktion war Frust. Aber als ich darüber nachdachte, wurde die wichtigere Lektion klar.

Das wird wieder passieren.

I must say I feel exhausted after these two weeks.

Emin Mahrt · Aus der Originalaufnahme

Das ist das Umfeld, in dem wir bauen

Nuri verbindet viele verschiedene Finanzsysteme. Banking, Karten, Bitcoin, Lightning, lokale Währungen und Zahlungswege funktionieren alle unterschiedlich. Einige Teile gehören uns. Andere verbinden uns mit externer Infrastruktur. Jeder Teil kann sich verändern, in Wartung gehen oder vorübergehend ausfallen.

Alle in diesem Bereich bauen schwierige Systeme, wir eingeschlossen. Veränderungen und Unterbrechungen gehören zu dieser Arbeit. Wir haben uns entschieden, diese Systeme zusammenzubringen. Deshalb tragen wir die Verantwortung dafür, was Nutzer erleben, wenn sich etwas ändert.

Unsere Aufgabe ist nicht, so zu tun, als würden alle beweglichen Teile für immer perfekt funktionieren. Unsere Aufgabe ist, dafür zu sorgen, dass Nuri nützlich bleibt, wenn einer davon ausfällt.

if you're building a puzzle with many moving parts, of course, those moving parts are going to work, going to not work, going to break.

Emin Mahrt · Aus der Originalaufnahme

Ein Fallback muss funktionieren, wenn man ihn braucht

Der frustrierendste Moment war nicht, dass ein Feature nicht mehr funktionierte. Das kann passieren.

Frustrierend war, dass ein Fallback genau in der Situation nicht mehr verfügbar war, in der die Nutzer ihn brauchten.

Das hat uns etwas sehr Einfaches beigebracht: Ein Fallback, der nur unter normalen Bedingungen funktioniert, ist kein besonders guter Fallback.

Wir müssen überall dort, wo wir können, weitere Single Points of Failure beseitigen. Manchmal heißt das, einen weiteren Weg hinzuzufügen. Manchmal heißt es, Nutzern die Wiederherstellung oder den Ausstieg zu ermöglichen, ohne von uns abhängig zu sein. Und manchmal heißt es einfach, zwei Features voneinander zu trennen, die ähnlich aussehen, aber aus völlig unterschiedlichen Gründen ausfallen.

Bitcoin und Bitcoin Lightning sind ein gutes Beispiel. Für viele Nutzer sehen sie vielleicht wie zwei Varianten derselben Sache aus. Technisch sind es sehr unterschiedliche Systeme mit unterschiedlichen Kompromissen und unterschiedlichen Arten auszufallen. Sie als ein einziges nahtloses Guthaben darzustellen, sieht vielleicht aufgeräumter aus. Es bedeutet aber auch, dass ein Lightning-Problem den Eindruck erwecken kann, die gesamte Bitcoin-Nutzung sei kaputt.

Bis auf Weiteres ist es ehrlicher und nützlicher, sie zu trennen. Bitcoin kann weiter funktionieren, wenn Lightning nicht verfügbar ist. Lightning kann seinen aktuellen Status klar anzeigen. Nutzer sollten den technischen Grund nicht verstehen müssen. Sie müssen nur wissen, was funktioniert, was nicht funktioniert und was sie als Nächstes tun können.

Wir haben zu sehr versucht, die Technik zu verstecken

Lange wollte ich, dass Nuri die ganze Komplexität versteckt.

An vielen Stellen ist das immer noch das Ziel. Niemand sollte Nodes, Liquidität, Zahlungsrouting oder Infrastrukturanbieter verstehen müssen, um Geld zu senden.

Aber Komplexität zu verstecken darf nicht bedeuten, die Realität zu verstecken.

Wenn ein Zahlungsweg vorübergehend nicht verfügbar ist, sollte die App das sagen. Wenn etwas gewartet wird, sollte es auch so aussehen. Wenn eine Währung als Zahlungsweg, aber nicht als Guthaben unterstützt wird, sollte die Oberfläche diesen Unterschied deutlich machen.

Bisher haben wir versucht, Hinweise wie „vorübergehend nicht verfügbar“ zu vermeiden. Sie wirkten technisch und unfreundlich. Rückblickend hat das die Erfahrung verschlechtert. Ein Button, der verfügbar aussieht, aber nach dem Antippen nicht funktioniert, ist viel frustrierender als ein ausgegrauter Button mit einer klaren Erklärung.

Das verändert, wie wir über den Hauptbildschirm von Nuri denken. Er sollte nicht nur zeigen, wo dein Geld ist. Er sollte auch zeigen, was du gerade damit tun kannst.

Vielleicht hast du Geld in Euro, aber mehrere Möglichkeiten, diese Euro zu nutzen: Kartenzahlungen, Banküberweisungen oder die Umwandlung in eine andere Währung. Manche Zahlungswege brauchen gar kein eigenes Guthaben. Sie sind einfach nur eine weitere Möglichkeit, Geld zu senden oder zu empfangen.

Gleichzeitig dürfen wir dasselbe Geld niemals zweimal anzeigen. Wenn deine Karte und dein Bankkonto dasselbe zugrunde liegende Guthaben nutzen, kann die Anzeige des Betrags an beiden Stellen den Eindruck erwecken, du hättest doppelt so viel Geld, wie du tatsächlich hast.

Die erste Version ist vielleicht nicht schön, aber sie muss klar sein.

Der Support sollte wissen, was die App weiß

Diese Woche hat auch verändert, wie ich über Support denke.

Der Support sollte kein getrenntes System mit einer veralteten Liste von Features sein. Er sollte dasselbe Nuri verstehen, auf das der Nutzer gerade blickt.

Wenn ein Zahlungsweg nicht verfügbar ist, sollte der Support es sofort wissen. Wenn ein Feature deaktiviert wurde, sollte unser Support-Agent es nicht empfehlen. Wenn jemand fragt, warum eine Lightning-Rechnung nicht bezahlt werden kann, sollte der Support sehen können, ob der Zahlungsweg funktioniert, die aktuelle Situation erklären und eine verfügbare Alternative vorschlagen.

Hier wird unsere Arbeit an MCP praktisch.

MCP klingt technisch, aber die Grundidee ist einfach: Jede Funktion von Nuri soll über eine saubere Schnittstelle verfügbar sein, die sowohl die App als auch Agents verstehen können.

Das Nuri MCP sollte die Features enthalten, die in Nuri wirklich verfügbar sind. Experimentelle Features sollten woanders bleiben, bis sie bereit sind.

Im Moment sind diese Grenzen nicht immer sauber. Experimente, App-Features und unabhängige Services liegen bei uns zu nah beieinander. Das war sinnvoll, solange wir schnell vorangekommen sind und Ideen getestet haben. Jetzt, da wir wollen, dass Agents echte Nutzer unterstützen, ist es weniger sinnvoll.

Wenn etwas in Nuri verfügbar wird, sollte der Support-Agent es verstehen. Wenn etwas aus der App verschwindet, sollte es auch aus den verfügbaren Aktionen des Agents verschwinden. App, Support und Infrastruktur sollten dieselbe Realität beschreiben.

Wir warten nicht auf Perfektion

Wir können Monate damit verbringen, für jeden denkbaren Ausfall den perfekten Fallback zu entwerfen. Dann starten wir und stellen fest, dass die Nutzer etwas völlig anderes verwirrt.

Wir brauchen echte Nutzer.

Wir brauchen Menschen, die Nuri öffnen, versuchen, es zu benutzen, und uns sagen, wo sie nicht weiterkommen. Nicht weil sie eine Theorie über unsere Oberfläche haben, sondern weil sie etwas tun wollten und es nicht konnten.

Dieses Feedback ist wertvoller als zehn interne Meinungen.

Ein Beispiel dafür zeigte sich bei der Trennung von Karten und Banküberweisungen. Technisch kann es logisch wirken, beides zusammenzulegen, weil sie dasselbe Guthaben nutzen können. Aber Nutzer fragten immer wieder, wo ihre IBAN sei. Sie öffneten die Kartenansicht, sahen eine Karte und suchten nicht weiter. Sie erwarteten nicht, dass Banküberweisungen dort versteckt sind.

Nutzer müssen nicht wissen, warum wir zwei Dinge ursprünglich zusammengefasst haben. Sie wissen nur, dass sie nicht finden konnten, was sie brauchten.

Also werden wir mit unfertigen Screens und Abläufen schneller vorangehen. Dann beobachten wir, wo Menschen nicht weiterkommen, und verbessern diese Stellen. Manches wird nicht perfekt aussehen, und manche Experimente werden scheitern. Eine Idee kann in einem Meeting sinnvoll klingen und sich in dem Moment falsch anfühlen, in dem jemand sie ausprobiert.

Das erfahren wir lieber jetzt.

it's okay that things break it's okay that they don't look good we just react on it and basically make the best out of it

Emin Mahrt · Aus der Originalaufnahme

Was wir als Nächstes tun

Wir werden die App weiter verbessern, aber wir werden auch anfangen, mehr Menschen in die App zu holen. Distribution darf nicht die Aufgabe bleiben, die wir jedes Mal verschieben, wenn etwas kaputtgeht.

Wir trennen Features, damit ein nicht verfügbarer Zahlungsweg nicht den Rest der Nutzung beeinträchtigt, ergänzen klarere Statusinformationen und räumen das Nuri MCP auf, damit es zur App passt. Der Support sollte wissen, welche Funktionen gerade verfügbar sind. Besseres Monitoring hilft uns, Probleme zu finden, bevor daraus lange Supportgespräche werden.

Für Lightning werden wir uns die verfügbaren Optionen ansehen, ohne uns überstürzt die nächste dauerhafte Abhängigkeit einzuhandeln.

Es gibt mehrere mögliche Schritte. Wir können reguläre Swaps zwischen Bitcoin und Lightning unterstützen, später schnellere Varianten untersuchen, andere Non-Custodial-Ansätze prüfen oder unsere aktuelle Integration weiter verbessern, sobald die nötigen Funktionen verfügbar sind.

Wir müssen nicht heute jede Entscheidung treffen.

Bitcoin kann nützlich bleiben, ohne dass wir so tun, als wäre schon jeder Anwendungsfall für Lightning gelöst. Lightning ist schwierig, und die gesamte Branche arbeitet noch an einigen harten Problemen. Wir sind lieber ehrlich, als eine nahtlos wirkende Nutzung zu erzwingen, die verwirrend wird, sobald sich etwas ändert.

Dasselbe Prinzip gilt auch jenseits von Bitcoin. Wenn ein Zahlungsweg für eine lokale Währung in Wartung geht, sollte der Rest von Nuri weiter funktionieren. Wenn ein Kartendienst nicht verfügbar ist, sollten Nutzer trotzdem ihre Optionen für Banküberweisungen finden. Wenn ein Feature experimentell ist, sollte es nicht still und leise so wirken, als wäre es produktionsreif.