Welches Ihrer zehn Produkte ist gerade kaputt?

Sie haben zehn Dinge gestartet. Zusammen zahlen sie die Miete. Einzeln verdient keines davon genug, um einen Montagmorgen zu verdienen — also bekommt auch keines einen.

Das ist der Handel, und es ist ein guter Handel. Er hat eine Lücke.

Das Portfolio funktioniert nur, wenn jedes Produkt fast nichts kostet

Das Ein-Personen-Portfolio ist heute ein tragfähiges Geschäft, weil nahezu jeder wiederkehrende Kostenpunkt pro Produkt wegautomatisiert wurde. Deployments passieren beim Push. Zahlungen, Rechnungen und fehlgeschlagene Einzüge sind das Problem von jemand anderem. Die Datenbank ist verwaltet und das Hosting skaliert sich selbst. Support ist eine Dokumentationsseite und ein Postfach, in das Sie donnerstags schauen. Fehler landen in einem Tracker. Ein Uptime-Monitor pingt jede URL an und bleibt still.

Jedes davon hat eine Aufgabe beseitigt, die früher mit der Zahl Ihrer Produkte mitwuchs. Das ist der ganze Trick: Das zehnte Produkt lohnt sich nur deshalb, weil es Sie fast nichts kostet, es zu halten.

Ein wiederkehrender Kostenpunkt bleibt, und es ist genau der, den Sie auslassen: zu wissen, dass das, wofür Menschen bezahlen, immer noch tut, wofür sie bezahlen. Sie lassen ihn aus, weil das Auslassen keine unmittelbaren Folgen hat. Genau das macht ihn gefährlich.

Die Ausfälle, auf die es ankommt, werfen keine Fehler

Stellen Sie sich vor, woran ein stilles, profitables, unbeaufsichtigtes Produkt tatsächlich stirbt.

Ein Zahlungsanbieter stellt die API-Version ab, auf die Sie festgelegt haben. Die Kassenseite wird angezeigt, der Button dreht sich, und es wird nie eine Karte belastet.
Eine Versanddomain wird nach einer DMARC-Änderung gesperrt. Die Registrierung wird abgeschlossen. Die Bestätigungsmail kommt nie an, also kann niemand die Kontoerstellung beenden. Ihre Anwendung sieht kein Problem — sie hat die Nachricht erfolgreich übergeben.
Ein OAuth-Zustimmungsbildschirm muss neu verifiziert werden. „Mit Google anmelden“ zeigt jetzt einen Warnhinweis zu einer nicht verifizierten App. Jede Besucherin liest das als Betrugsversuch und geht.
Ein Dependency-Update ändert die Voreinstellungen einer Formularbibliothek. Das Absenden validiert nun ein Feld, das immer leer ist, also wird das Formular nie abgeschickt — und meldet auch nie einen Fehler, denn das Absenden zu verweigern ist genau der Zweck von Validierung.
Eine Datenbank im kostenlosen Tarif pausiert nach Inaktivität. Die erste Anfrage des Tages weckt sie, läuft in ein Timeout und zeigt einen leeren Zustand, der aussieht wie ein Produkt ohne Daten darin.
Eine CSS-Änderung schiebt den Kaufen-Button auf dem Handy unter die Falz, hinter das Cookie-Banner.

Die Liste hat eines gemeinsam. In jedem Fall hat der Server geantwortet, kein Code hat eine Ausnahme geworfen, und keine Kundin hat sich beschwert.

Niemand hat sich beschwert, weil die Leute, die darauf gestoßen sind, Fremde waren. Sie hatten Ihre E-Mail-Adresse nicht und schuldeten Ihnen keinen Fehlerbericht. Die Kundschaft, die es Ihnen gesagt hätte, ist genau die, die nie Kundschaft geworden ist.

Uptime ist eine Aussage über Ihren Server, nicht über Ihr Produkt

Ihr Monitor lügt Sie nicht an. Er beantwortet eine engere Frage als die, die Sie gestellt zu haben glaubten.

Ein Pinger stellt fest, dass eine URL eine 200 zurückgegeben hat. Eine Kassenseite, die keine Karte belasten kann, gibt eine 200 zurück. Ein Registrierungsformular, das keine Mail verschickt, gibt eine 200 zurück. Und eine Seite, die einen leeren Zustand aus einer gerade erst aufgewachten Datenbank zeigt, ebenfalls.

Ein Fehler-Tracker stellt fest, dass Ihr Code keine Ausnahme geworfen hat. Nichts aus der obigen Liste hat eine geworfen. Eine gesperrte Versanddomain ist ein erfolgreicher API-Aufruf. Ein Formular, das sich weigert abzuschicken, ist Validierung, die wie vorgesehen arbeitet.

Beide Instrumente sind ihr Geld wert, und keines von beiden beobachtet, ob eine Kundin ans Ziel kommt. Das ist eine andere Frage, und sie braucht ein anderes Instrument.

Drei Sätze pro Produkt, nicht drei Test-Suites

Der Umfang klingt unmöglich und ist es nicht, denn Sie müssen keine zehn Produkte testen. Sie müssen den Geldweg durch zehn Produkte testen, und der ist kurz.

Bei praktisch jedem Produkt gibt es drei Abläufe, die Umsatz tragen:

Eine Fremde kann Nutzerin werden.
Eine Nutzerin kann Sie bezahlen.
Wofür sie bezahlt hat, tut, was es tun soll.

Zehn Produkte mit je drei Abläufen sind dreißig Prüfungen. Das klingt nach viel — bis Sie merken, dass es dreißig Sätze sind und nicht dreißig Repositories:

Mit einer neuen E-Mail-Adresse registrieren, das Konto über die
Bestätigungsmail bestätigen und auf dem Dashboard landen.

Mit einer Testkarte auf den Pro-Tarif wechseln und sehen, dass der
Tarif auf der Rechnungsseite auf Pro steht.

Eine URL in das Feld einfügen, ausführen und einen Bericht mit
mindestens einer Zeile erhalten.

Schreiben Sie sie so, wie Sie das Produkt einer Freundin beschreiben würden. Wenn Sie den Ablauf nicht in einem Satz beschreiben können, ist das für sich genommen schon wissenswert.

Warum Sie das noch nicht getan haben, und warum Sie recht hatten

Es lohnt sich, das klar zu sagen: Das auszulassen war keine Faulheit. Es war Arithmetik, und die Arithmetik stimmte.

Eine Playwright-Suite ist ein echtes technisches Artefakt: Selektoren, Fixtures, angelegte Testkonten, eine CI-Pipeline zum Ausführen und eine Wartungsrechnung jedes Mal, wenn Sie einen Button verschieben. Zehn davon sind keine Teststrategie, sondern ein Zweitjob. Schlimmer noch: Die Wartung skaliert pro Produkt, während der Umsatz ebenfalls pro Produkt anfällt und viel kleiner ist. Für etwas, das zweihundert im Monat einbringt, kostet ein Nachmittag Reparatur kaputter Selektoren mehr als der Ausfall, den er verhindert hätte.

Also haben Sie das Vernünftige getan und stattdessen das elfte Produkt gestartet.

Was sich geändert hat, ist nicht Ihre Disziplin. Es ist, dass die Kosten einer Prüfung pro Produkt weit genug gefallen sind, dass dreißig davon kein Zweitjob mehr sind.

Was Ihnen das immer noch nicht abnimmt

Zwei ehrliche Grenzen, denn eine Prüfung, die überverkauft wird, ist eine Prüfung, der Sie irgendwann nicht mehr glauben.

Sie wird Ihnen nicht sagen, dass ein Produkt aufgehört hat zu zählen. Alle drei Abläufe können jeden Tag bestehen, während das Produkt still an fehlender Nachfrage, fehlendem Traffic und fehlender Daseinsberechtigung eingeht. Das ist ein realer Ausfallmodus für ein Portfolio, und kein Monitor erkennt ihn.

Randfälle deckt sie ebenfalls nicht ab. Sie decken bewusst den Geldweg ab und lassen den Rest offen, was in dieser Größenordnung die richtige Abwägung ist — und trotzdem eine Abwägung.

Und wenn ein Produkt neun Dollar im Monat einbringt, lautet die Antwort vielleicht, es einzustellen statt es zu überwachen. Ein Portfolio ist eine Reihe von Entscheidungen, kein Museum.

Wohin das führt

Das Hindernis war nie, zu wissen, was zu prüfen ist — die dreißig Sätze könnten Sie heute Nachmittag aufschreiben. Es war, dass daraus etwas Laufendes zu machen den Bau und die Pflege einer Test-Suite pro Produkt verlangte, also genau die Kosten, zu deren Vermeidung das Portfolio-Modell überhaupt existiert.

Diese Lücke soll Testmode schließen: Sie schreiben den Ablauf als Satz, er läuft gegen das echte, ausgelieferte Produkt in einem echten Browser in dem Takt, den Sie wählen, und er sagt Ihnen, wann eine Kundin gescheitert wäre — ohne Testcode, ohne Pipeline und ohne irgendetwas in einem der zehn Repositories zu installieren. Wenn Sie lieber das Vorgehen als das Argument wollen, behandelt Regressionstests ohne QA-Team, wie Sie die Abläufe auswählen und was zu tun ist, wenn einer fehlschlägt.