Die App, die ich entworfen und gebaut, aber nie veröffentlicht habe: Stocketa
(paulstamatiou.com)- In der frühen Phase der Corona-Isolation im März 2020 begann Stocketa als persönliches Projekt zum Lernen von Swift und SwiftUI und wurde über mehr als zwei Jahre hinweg 10–20 Stunden pro Woche entwickelt, aber nie im App Store veröffentlicht
- Das Ziel war ein Portfolio-Tracker für Gelegenheitsanleger, der verstreute Vermögenswerte aus verschiedenen Brokern und Finanzdiensten an einem Ort zeigt und sogar Gewinn/Verlust pro Trade sowie realisierte und nicht realisierte Gewinne/Verluste sichtbar macht
- Die App konzentrierte sich stärker auf selbst entwickelte Interaktionen als auf Standard-iOS-Komponenten und implementierte pull-to-search, Aktienkarten, benutzerdefinierte Sheets und Menüs, Swipe-Aktionen, Widgets und TSV-Import
- Die größte praktische Hürde für die Veröffentlichung waren Finanzdaten-APIs; Probleme bei Qualität und Abdeckung von IEX, die Unzuverlässigkeit eines Anbieters für 100 $/Monat und Preise ab 2.000 $/Monat für kommerzielle Daten passten nicht zu einer unabhängigen App
- Obwohl es bereits eine LLC, ein Node/Express-Backend, ein TestFlight mit rund 1.000 Personen und mehrere tausend Interessenten auf der Warteliste gab, wurde das Projekt wegen Datenkosten, Supportaufwand und Zeitmangel eingestellt; die SwiftUI-Lernerfahrung floss später direkt in die Arbeit bei Rewind AI ein
Das Problem, das Stocketa lösen wollte
- Stocketa zielte auf eine gut gestaltete Portfolio-Tracking-App, mit der sich über mehrere Orte verteilte Investment-Assets auf einem Bildschirm überblicken lassen
- Ausgangspunkt war die persönliche Erfahrung, dass es mühsam war, Vermögenswerte zu prüfen, die über mehrere Broker und Finanzdienste verteilt waren
- Gewünscht war nicht nur eine einfache Kursansicht, sondern ein Blick auf den tatsächlichen Gewinn oder Verlust pro Trade auf Basis der eigenen Einstandskosten
- Die damaligen Optionen passten nicht zu den Anforderungen
- Einfache Aktien-Apps wie Apple Stocks boten Charts und News, aber keine Funktionen zum Verfolgen von Beständen und Gewinnen/Verlusten
- Broker-Apps wie Robinhood zeigten nur die Bestände innerhalb des jeweiligen Brokers
- Fortgeschrittene Dienste wie TradingView waren nicht mobile-first oder boten nicht die gewünschte elegante Experience
- Investmentberatungsdienste wie Personal Capital konnten zwar Konten verknüpfen, erschwerten aber den tiefen Blick auf einzelne Assets und waren vor allem auf den Verkauf eigener Beratungsleistungen ausgerichtet
- Kleinere Apps im App Store zum Tracking von Beständen überzeugten nicht bei Design und UX
- Bestehende Finanz-Apps priorisierten meist Informationsdichte, sodass man sich immer weiter von Listen in Detailansichten hineinklicken musste; Stocketa wollte mehr Informationen direkt in den Karten der ersten Ansicht zeigen
App-Struktur mit Custom UI
- Stocketa wurde rund um einen einzelnen Feed und Aktienkarten entworfen, mit möglichst wenig zusätzlichem UI-Chrome
- Eine Standard-Tab-Bar oder Navigations-Header sollten vermieden werden
- Die meisten Funktionen waren innerhalb der Aktienkarten der Home-Timeline untergebracht
- Fast die gesamte UI wurde als Custom Components auf SwiftUI-Basis gebaut
- Statt pull-to-refresh kam pull-to-search zum Einsatz, um neue Titel zu suchen und hinzuzufügen
- Aktienkarten boten die meisten Informationen inline, darunter Chart-Scrubbing, Swipe-Aktionen und zentrale Kennzahlen
- Beim Tippen auf eine Karte blieb die bestehende Karte an Ort und Stelle, während Karten mit News und Bestandsdetails animiert eingeblendet wurden; für die Kernimplementierung wurden
overlayPreferenceValueundanchorPreferenceverwendet - Custom Sheets enthielten einen Date-Picker, Einführungsbildschirme, einen funkelnden Sternenhintergrund und eine Interpolation der Hintergrundtransparenz beim Ziehen
- Ein Custom App-Menü bot Platz für die Anzeige von kostenpflichtigen Plänen oder Mitgliedschaftsstatus und war so gestaltet, dass es sich per Tap oder Scroll schließen ließ
- Auch Swipe-Aktionen und Header wurden selbst implementiert
- Je nach Swipe-Distanz bewegten sich die Aktionen, und ab einem bestimmten Schwellenwert wurden sie animiert in einen ausgewählten Zustand überführt
- Header-Buttons erschienen oben auf der Seite zunächst ohne Umrandung und wechselten beim Scrollen zu dezenten Buttons
- Der Text „Stocketa“ wurde beim Scrollen nach oben interpoliert ausgeblendet
Trade-Tracking und App-Funktionen
- Die erste Implementierung begann mit der Scroll-View der Aktienkarten, Charts und Datenbank-Persistenz
- Zunächst wurde Core Data verwendet, später erfolgte der Wechsel zu Firebase
- Anbindungen und Polling für Finanzdatenanbieter wurden ergänzt; als erster Anbieter wurde IEX genutzt
- Stocketa speicherte nicht nur die Anzahl gehaltener Aktien pro Titel, sondern implementierte Tracking auf Trade-Ebene
- Es sollte nicht nur der Gesamtgewinn oder -verlust aus Käufen und Verkäufen angezeigt werden, sondern auch Gewinn oder Verlust pro Trade
- Beim Verkauf mussten Kostenbasis-Methoden wie FIFO und LIFO berücksichtigt und berechnet werden, aus welchen früheren Trades die verkauften Aktien stammen
- Bei Aktiensplits sollten frühere Trades nicht einfach überschrieben werden; stattdessen mussten sowohl automatische Anwendung neuer Splits als auch manuelle Anwendung unterstützt werden
- Die Funktionen wurden auf die gesamte App ausgeweitet
- Onboarding: Statt eines gewöhnlichen Karussells kam ein Ablauf zum Einsatz, bei dem Seiten entlang der z-Achse hereingeschoben wurden und zentrale Komponenten wie Aktienkarten vorgestellt wurden
- TSV-Import: Trades konnten aus TSV-Dateien aus Tabellenkalkulationen importiert werden, und der Importstatus wurde zurück in die TSV geschrieben, um nach iCloud-Sync einen Reimport zu ermöglichen
- Kauf-Eingabe: Ein aktienspezifisches Formular mit Fokus auf Menge, Preis und Datum; beim Ändern des Datums wurde der historische Kurs dieses Tages als Placeholder angezeigt
- Verkauf-Eingabe: Unterstützung für FIFO, LIFO, Average cost, Highest cost, Lowest cost und bestimmte Lots
- Abo-Bildschirm: Mit Parallax-Text, scrollabhängigem Unblur, bewegungsbasierten Feature-Karten und einem kleinen Fireworks-Effekt am unteren Ende
- Mitgliedschaftskarte: Zeigte den Status eines Kontos mit aktivem Abo als interaktive Karte mit Starfield-Effekt im Hintergrund und Shimmer-Effekt
- Einstellungen für die Anzeige von Aktienkarten: Bot mehrere Kartenformen und Einstellungen sowie Mikroanimationen beim Umschalten
- Bestandsübersichtskarte: Zeigte am oberen Rand des Haupt-Scrollbereichs aggregierte Informationen auf Basis der Einstellungen
- Widgets: Drei Typen wurden angeboten — einzelne Aktie, Portfolio und einfaches Portfolio —, wobei sich große Farbverläufe je nach Performance änderten
- Face-ID-Aufschubzeit: Weil dies für eine App mit Finanzvermögen wichtig erschien, ließ sich einstellen, wie lange die App beim Wechseln zwischen Apps entsperrt bleibt, bevor sie erneut gesperrt wird
- Sheet für Marktfeiertage: Zeigte Schließtage für Aktienkonten an; dafür war auch Server-Code nötig, damit Widgets dasselbe Verhalten übernehmen konnten
- Feedback-Sheet: Zeigte bekannte Probleme und geplante Funktionen und konnte bei kontospezifischen Fragen einen Token zur Kontoidentifikation enthalten
- Konto löschen: Entsprechend einer App-Store-Anforderung von 2021 konnte ein Konto vollständig in der App gelöscht werden
Mit SwiftUI lernen und immer wieder neu bauen
- Stocketa entstand parallel zum Lernen von Swift und SwiftUI, weshalb viele Screens und Teile der App wiederholt neu entworfen und neu implementiert wurden
- SwiftUI entwickelte sich seit iOS 13 bei Performance, Komponenten und Features weiter; in iOS 17 kamen auch Funktionen wie shaders, keyframes und scroll transitions hinzu
- SwiftUI erwies sich nicht nur als Code-Tool, sondern auch als Design-Tool
- Designer konnten schnell Layouts erstellen
- Interaktionen ließen sich leicht hinzufügen
- Mit nativen Tools ließ sich ein echtes Designgefühl prüfen
- Fälle, in denen UIKit nötig war, blieben begrenzt
- Custom Text Fields für feinere Kontrolle über Eingabe, Stil und Formatierung
- CollectionView zum Ändern der Reihenfolge von Titeln per Drag-and-drop
- Partikel-Emitter für confetti oder Sterne am Nachthimmel
UILongPressGestureRecognizer, um die Startposition eines langen Drucks zu erhalten
Backend und Betrieb über TestFlight
- Anfangs war eine einfache App ohne Backend oder Benutzerkonten geplant, doch bald wurde ein eigenes Backend nötig
- Es wurde ein Backend-Proxy gebaut, damit API-Keys für Finanzdaten nicht in der App selbst liegen
- Um Mehrkosten durch API-Missbrauch zu vermeiden, wurden rate-limiting und throttling ergänzt
- Sign In With Apple wurde hinzugefügt
- Kennzahlen pro Titel wurden für eine gewisse Zeit gecacht, damit bei mehreren Konten mit gleicher Anfrage die Daten nur einmal geladen werden mussten
- Das Backend wuchs auf Basis von Node/Express auf etwa 13.000 LOC an
- Es lief auf Cloud Run
- Es war zuständig für Authentifizierung, Caching, News, zentrale Business-Logik, Datenbereinigung, Benachrichtigungen, Widgets, verschiedene API-Integrationen und teilweise Scraping
- Das Arbeitsmanagement lief über Linear
- Dort wurden Aufgaben, Ideen, Features, Kundenfeedback und Milestones verwaltet
- TestFlight begann als kleine Alpha für enge Freunde und wurde schrittweise ausgeweitet
- Zeitweise wurden rund 1.000 Personen eingeladen
- Obwohl mehrere tausend Menschen auf der Warteliste standen, wurde die Zahl wegen API- und Hosting-Kosten sowie wegen des Aufwands für Support und Feedbackbearbeitung nicht weiter erhöht
- Das Feedback umfasste gute Ersteindrücke, Feature-Wünsche und Bug-Reports
Design und Umsetzung der Website
- Die frühe Website war eine einfache Landingpage, um Interesse zu wecken und E-Mail-Adressen für die Warteliste zu sammeln
- Das frühe Design enthielt Wellenelemente, die lose die Auf- und Abbewegung von Börsencharts aufgriffen, sowie schwebende Mini-Aktienkarten
- Die Mini-Karten enthielten SVG-Liniendiagramme und wurden beim Laden der Seite animiert
- Der sanft bewegte Effekt im Hintergrund wurde mit
offset-path-CSS und zwei keyframe-Animationen umgesetzt
- Die Homepage
v1.0wurde Anfang 2021 fertiggestellt- Zu diesem Zeitpunkt war genug von den App-Funktionen umgesetzt, um eine ausgereiftere Homepage zu bauen
- Statt des üblichen Aufbaus aus Smartphone-Rahmen plus Headline wurde ein Layout ausprobiert, bei dem sich ein 3D-Smartphone-Rahmen beim Scrollen bewegt und ein Teaser-Video der App abgespielt wird
- Statt Lottie wurde JavaScript verwendet, das eine Frame-Sequenz auf
canvasundoffscreenCanvaszeichnete - Mit Rotato wurden kurze Stocketa-Screencasts als 3D-Smartphone-Video und PNG-Frame-Sequenz erstellt
- Die spätere Erzeugung, Optimierung und Aktualisierung der Frame-Sequenzen wurde zu einem großen Ärgernis
- Die Homepage
v2.0wurde ein Jahr später neu gestaltet- Um mehr Features und Verbesserungen zu zeigen, wurde statt langer, repetitiver Module eine leicht erfassbare Feature-Liste angestrebt
- Gewählt wurde eine Zwei-Panel-Struktur mit feststehendem Geräterahmen rechts und scrollbarer Feature-Liste links
- Beim Überfahren eines Feature-Eintrags mit der Maus wechselte der Screenshot im Geräterahmen
- Auf Mobilgeräten wurde der Header in ein scrollbares Karussell aus Geräterahmen umgewandelt
- Zusätzlich kamen scrollabhängige Farbverläufe für Hero-Text, veränderliche Icon-Farben, Hover-Hintergrundverläufe und Partikel-Emitter für Icons hinzu
Grenzen durch Finanzdaten-APIs
- Die Qualität der Finanzdaten, auf die Stocketa angewiesen war, reichte nicht für eine veröffentlichungsreife App aus
- Beim ersten Anbieter IEX gab es mehrere Probleme
- Charts waren teils veraltet oder Preise ungenau
- Besonders groß waren die Probleme bei Assets mit geringem Handelsvolumen an der IEX-Börse
- Es gab keine Daten für den OTC-Markt, und dafür hätte direkt mit OTC eine teure Lizenz abgeschlossen werden müssen
- Auch Daten zu an der Nasdaq gelisteten Aktien waren stark eingeschränkt, und selbst grundlegende Daten wie Premarket und After-Hours fehlten
- Daten zu Mutual Funds wurden ohne Vorankündigung vollständig eingestellt
- Ein später genutzter anderer kommerziell nutzbarer Anbieter kostete 100 $ pro Monat, hatte aber noch größere Probleme bei Daten und Zuverlässigkeit
- Endpunkte lieferten veraltete oder falsche Daten zurück
- Gemeldete Probleme wurden ignoriert oder als nicht existent bezeichnet
- Einige Daten waren selbst über bezahlte APIs schwer zu bekommen, sodass im Backend eine Scraping-Engine gebaut werden musste
- dividend yield
- earnings dates
- OEF-Daten
- Hochwertige Marktdaten hatten eine Preisstruktur, die nicht zu unabhängigen App-Entwicklern passte
- Die Preise für kommerzielle Daten bei einigen wichtigen US-Marktdatenanbietern begannen bei 2.000 $ pro Monat
- Indexdaten oder Optionsdaten erforderten zusätzliche Kosten
- Ein Anbieter schlug einen Startup-Plan für 499 $ pro Monat plus Gebühren pro MAU vor, was dennoch als viel zu teuer für den Bedarf eingeschätzt wurde
- Projekte, die auf Finanzdaten-APIs basieren, tragen das Risiko, ein Geschäft auf den APIs externer Unternehmen aufzubauen; das wurde als ähnliches Problem wie bei den API-Änderungen von Twitter und Reddit gesehen
Warum die Veröffentlichung gestoppt wurde
- Stocketa war von Anfang an ein Side Project und kein echtes Unternehmen
- Um daraus ein wirkliches Geschäft zu machen, wären mehr Funktionen und ein Monetarisierungsmodell nötig gewesen
- Möglicherweise hätte man in Bereiche wie Finanzberatung oder Aktienhandel vorstoßen müssen, also in dicht besetzte Felder mit Konkurrenz durch große Unternehmen
- Diese Richtung passte nicht zum ursprünglichen Ziel, eine einfache und elegante App zu bauen
- Die Gründe für das Ende lassen sich in drei Punkten zusammenfassen
- Daten: Um die App zu einem vernünftigen Abo-Preis veröffentlichen zu können, wären verlässliche, günstige und qualitativ hochwertige Finanzdaten nötig gewesen, doch sowohl Kosten als auch Beschaffung waren schwierig
- Support: Das Nutzungsverhalten in TestFlight zeigte, dass Kundensupport, E-Mails, Wartung und kontinuierliche Weiterentwicklung erhebliche Investitionen erfordert hätten
- Zeit: Rewind AI wurde zum Fokus, und Stocketa hatte über Jahre hinweg Abende, Wochenenden und sogar Zeit für Blogposts verschlungen
- Das ursprüngliche Ziel, Swift und SwiftUI zu lernen, wurde erreicht
- Auch ohne Veröffentlichung wurde viel über native iOS-Entwicklung gelernt
- Das in Stocketa erworbene SwiftUI-Wissen half später stark bei der Arbeit an Rewind AI
1 Kommentare
Meinungen auf Hacker News
Dass ein mehrjähriges Projekt am Ende nicht wirklich genutzt wird, fühlt sich fast wie ein Ehrenabzeichen an. Kein kluges Abzeichen, aber für Entwickler wie mich, die sich im positiven Sinne verrennen und völlig hineingezogen werden, ist es fast eine notwendige Lektion.
Wenn ich von früheren Erfahrungen und dem Schmerz erzähle, der daraus kam, habe ich das Gefühl, dass die Leute nur leer schauen. Wenn man nicht über ein Jahr lang mehr als 10 Stunden am Tag an etwas gearbeitet hat, ist es wohl schwer zu verstehen, wie es sich anfühlt, Tausende Stunden zu investieren und trotzdem keinerlei Ergebnis zu haben.
Es gibt viele erfolgreiche Projekte, und auch jetzt läuft vieles gut, aber diese mehrjährigen Projekte lassen sich nicht rückgängig machen. Für das Lernen waren sie vielleicht nötig, aber wenn ich daran denke, macht es mich immer noch traurig und einsam.
Dafür habe ich die Fähigkeiten erworben, ein deutlich besserer Programmierer zu werden, und Swift liebgewonnen. Heute könnte ich dank der Fortschritte bei Apples Entwicklerwerkzeugen und APIs in den letzten sieben Jahren vermutlich die gesamte App an einem Wochenende von Grund auf neu bauen.
Solche Projekte sind es wert, gewürdigt zu werden. Programmierung kann Kunst sein, und Kunst kann als kreatives Ventil auch nur für einen selbst entstehen.
Dieses ergebnisorientierte Denken, bei dem man sich mit später erworbenem Wissen über vergangene Projekte quält, ist wenig nützlich. Die meisten Projekte und Unternehmen scheitern, das ist die Realität.
Ich erinnere mich an einen Text eines ehemaligen Finanzmenschen, der schrieb: „Niemand wird gefeuert, weil er mit einem schlechten Deal zufällig Geld verdient hat.“ In einer ergebnisorientierten Kultur vergisst man leicht, dass das Einzige, was wir tatsächlich kontrollieren, der Prozess ist.
Ich habe zwar wertvolle Lektionen gelernt, etwa zu wissen, wann man aufhören sollte, aber es war eine viel zu lange Lektion. Ich kann immer noch nicht richtig darauf zurückblicken.
Ich frage mich, ob man empfehlen sollte, kein Projekt zu starten, das länger als ein Jahr dauert, wenn man nicht sicher ist, es auch dann nicht zu bereuen, wenn es niemand nutzt.
Ein großartiger Artikel, aber das Fazit wirkt traurig. Es gibt so viele Apps, bei denen man sich genau so eine „Version ohne unnötigen Kram“ wünschen würde, und der Arbeitsaufwand hier ist beeindruckend.
Ich habe eine einfachere iOS-App veröffentlicht, die über organisches Wachstum auf etwa 1.000 täglich aktive Nutzer kam, sie aber schließlich eingestellt. Ich hatte einen In-App-Kauf für 1,99 oder 2,99 US-Dollar zum Entfernen von Werbung eingebaut, verdiente etwa 70 US-Dollar im Monat und bearbeitete Bugreports.
SwiftUI war damals noch nicht ausgereift, also musste ich UIKit verwenden, und ich stieß immer wieder auf schwer zu behebende Randfälle.
Der entscheidende Schlag war, als Google behauptete, ich hätte auf meine eigenen Anzeigen geklickt, und die Anzeigenauslieferung stoppte. Damit war praktisch der gesamte Umsatz weg, und mir wurde klar, dass selbst wenn man so etwas mit viel Mühe baut, am Ende alles von den Launen der großen Tech-Konzerne abhängt.
Apple nahm 30 % von allen In-App-Käufen, Werbeeinnahmen waren Kleingeld, und Google konnte sie ohne Grund abschalten, ohne echte Möglichkeit zur Berufung. Ich wollte nicht reich werden, aber ich brauchte einen Grund, Zeit und Energie hineinzustecken, und das ließ sich nicht mehr rechtfertigen.
Ich verstehe nicht, warum Entwickler keine vom Umsatz ausgeschlossenen Geräte, IP-Bereiche oder Standortlisten eintragen können. Man nutzt die eigene App am Ende nun einmal selbst, und beim Scrollen ist es oft fast unmöglich, niemals versehentlich auf eine Anzeige zu tippen.
Tests unter realen Bedingungen sind ebenfalls wichtig, und es besteht sogar eine kleine Möglichkeit, dass eine Anzeige wirklich interessant ist und man als potenzieller Kunde legitim darauf klickt. Aber die aktuelle Vorgehensweise bedeutet im Grunde, die eigene App nicht zu benutzen.
Ich weiß nicht, wem eine so grundlegend dumme Richtlinie nützt, außer den Google-Entwicklern oder -Managern, die daran festhalten. Ist es wirklich so schwer, das auch nur ein bisschen vernünftig zu handhaben?
Ähnlich kann man an den Schlafzimmermusiker denken, der seit 20 Jahren weder aufgetreten ist noch ein Album veröffentlicht hat, an den Kindheitssportler, der seit seinem 18. Lebensjahr keinen Ball mehr berührt hat, an den Läufer, der an keinen Wettkämpfen teilnimmt, oder an einen Intellekt, der nicht lehrt.
Unter derselben Prämisse „externer Output = Wert“ ließe sich das sogar auf Menschen ausweiten, die Jahrzehnte gelebt haben, ohne Kinder zu bekommen. Das ist nicht meine Überzeugung, sondern nur der logische Verlauf dieses Gedankens.
Aber solche Urteile sind menschliche Konstrukte und wirken wie ein Spiegel des biologischen Imperativs, „unsere Kinder“, die wir lange in uns getragen haben, in die Welt hinauszuschicken. Wir fragen, warum sie nicht ein eigenes Leben bekommen sollten, und wünschen uns, dass sie als solche weiter Ergebnisse hervorbringen und einen Faden in die Zukunft spinnen.
Ob es der Gipfel von Moral, Ethik oder Freude ist, diesem Imperativ zu folgen – für manche Menschen ja, und ich möchte darüber nicht urteilen. Für manche ist es seltsamerweise aber nicht so.
Ich frage mich, ob ein Verkauf dieses Projekts in Betracht kommt. Das Konzept gefällt mir, und es scheint interessierte Kunden zu geben, aber die Belastung durch Support und die Kommerzialisierung scheinen nicht gewünscht zu sein.
Ich habe vor etwa einem Jahr einen Asset-Tracker (https://jch.app) gebaut, aber bei Funktionen und User Experience ist er noch längst nicht auf diesem Niveau.
Eine enorme Arbeit, und auch die ausführliche Dokumentation der Reise war großartig. Ich bin gespannt, was als Nächstes von rewind.ai kommt.
Es unterscheidet sich nicht groß davon, dass unzählige Menschen endlos Zeit in unzählige Projekte stecken, die für niemanden sonst eine große Bedeutung hatten. Es ist so etwas wie an Fahrrädern herumzuhacken oder sich mit Modelleisenbahnen zu beschäftigen.
Der Unterschied ist nur, dass Apps so leicht veröffentlicht, dokumentiert und archiviert werden können, während das bei „der Zeit, die man damit verbracht hat, seltsame Fahrradteile zu zerschneiden und zusammenzuschweißen“, schwierig ist, sofern man nicht alles auf YouTube stellt.
Natürlich tun das viele, und bis zu einem gewissen Grad hat es auch Sinn, aber wenn man versucht, Hobbys und persönliche Interessen in Produkte mit einem anderen Ziel als dem Selbstzweck zu verwandeln, verfehlt man auch ein wenig den Kern.
Das soll nicht heißen, dass dieser Text falsch ist. Er wirkt nicht klagend oder wütend, sondern eher so, wie anfangs gesagt: „Ich möchte es irgendwie irgendwo festhalten.“ Bei dem Großteil meines GitHub ist es genauso.
Eine solche vorschnelle Anpassung des Bewertungsmaßstabs kann wenig hilfreich sein, weil sie das tatsächliche Ergebnis verwischt. In diesem Fall fällt es dem Autor leicht, sich für die „verschwendete“ Mühe zu schämen, aber eine angemessenere Reaktion wäre wohl Dankbarkeit für das Gelernte.
Der Lerneffekt aus solchen Projekten ist enorm.
Dieser Text ist beängstigend, weil ich mich darin viel zu sehr wiedererkenne. Man versinkt tief darin, ein großartiges Produkt zu bauen, identifiziert sich mit der Rolle des Handwerkers und empfindet Abneigung gegen den „seelenlosen“ Ansatz aus schnellem, schmutzigem MVP und wiederholten Markttests.
Wenn man jemals im Subreddit r/SaaS war: Das ist genau das Gegenteil von dem, was mir als Softwareentwickler Spaß macht.
Aber ich weiß auch: Wenn man seine Denkweise gegenüber Markttests und schneller, schmutziger Iteration ändern kann, schafft das eher eine bessere Grundlage, um loszulassen und sich auf Handwerkskunst zu konzentrieren.
Verständlich. Ich baue auch immer noch ein Banking-Backend. Inklusive Core, Buchhaltung, Kunden, Konten, Zahlungen (SEPA und Karten), Benachrichtigungen (so etwas wie ServiceNow), Sanktionsprüfungen, Risiko- und Monitoring-Engine, Event-Flows und Reporting – inzwischen seit fünf Jahren.
Ich beginne zu zweifeln, ob es verrückt oder dumm war, mir so ein riesiges Vorhaben aufzuhalsen. Eine Landingpage habe ich noch nicht einmal entworfen, und der Code umfasst ungefähr 150.000 Zeilen.
Obwohl die bestehenden Plattformen viele Bugs, Einschränkungen und Sicherheitsprobleme hatten, hat es deutlich länger als fünf Jahre gedauert, genug Vertrauen zu gewinnen, um Kunden davon zu überzeugen, auf unsere Core-Banking-Plattform umzusteigen.
Dann wurden Mobile Apps wichtig, also fing ich auch noch an, native Apps zu bauen, und das war einfach zu viel. Am Ende kam der Burnout, dazu die Insolvenz, und deshalb würde ich von riesigen Projekten abraten.
Ich habe viel gelernt, aber die Verschwendung war es nicht wert. Zeit ist zu kostbar, um so vieles neu zu bauen. Heute mache ich nur noch „kleine“ Projekte mit maximal 6 bis 12 Monaten Laufzeit.
Außerdem frage ich mich, ob es möglicherweise Open Source sein könnte.
Wenn du keine Basisversion veröffentlichen kannst, ohne all das einzubauen, was du noch hinzufügen möchtest, solltest du erwägen, es vorerst beiseitezulegen.
In den letzten über 20 Jahren habe ich viele Projekte und Produkte gebaut, und zwei oder drei davon sind stark gewachsen. Die anderen haben Tausende Nutzer, aber keine kontinuierliche Einnahmequelle.
Eines davon, das zu einem profitablen Unternehmen wurde, habe ich als „Wochenend-Build“-Version veröffentlicht und dann über sieben Jahre hinweg ausgebaut.
Dieser vertraute Zustand kann zur Falle werden, die dich ständig weitere Vorab-Arbeiten vor dem Launch finden lässt. Deshalb kann es sinnvoll sein, das im Kopf neu zu rahmen.
Ich habe kürzlich gelesen, dass Leonardo DaVinci ein enormer Aufschieber war und sehr viele Projekte nie abgeschlossen hat.
Ich habe ihn immer dafür bewundert, dass er in so vielen Bereichen so erfolgreich war, aber nachdem ich das erfahren hatte, änderte sich meine Sichtweise: Aufschieben ist ein Teil von uns als kreativen Menschen.
Man kann es als Scheitern betrachten, aber man kann es auch als Teil des Prozesses neu interpretieren. Am Ende macht es uns einfach Freude, Dinge zu erschaffen.
Im Grunde hat er den üblichen Rat „Baue ein MVP, veröffentliche schnell und iteriere“ angenommen und dann genau das Gegenteil getan.
Ein großartiger Artikel über ein cool wirkendes Nebenprojekt. Ich las ihn interessiert und stieß dabei auf rewind.ai, das ebenfalls gut aussieht.
Bei etwas potenziell Invasivem wie kontinuierlicher automatischer Bildschirm- und Audioaufzeichnung ist Datenschutz zentral, daher kamen mir beim Abschnitt „Privacy first“ Fragen.
Dort steht: „Verschlüsseln Sie Ihre Daten mit FileVault. Apple FileVault funktioniert mit Rewind. Wenn Sie es aktivieren, werden Ihre Daten verschlüsselt.“ Tut Rewind irgendetwas dafür, dass Apple FileVault „mit Rewind funktioniert“?
Oder ist damit einfach die allgemeine Festplattenverschlüsselung gemeint, die für alles gilt? Ernst gemeinte Frage. Ich würde Rewind gern nutzen, aber diese Formulierung kann wie unnötige Verpackung wirken.
Ähnlich wirkt auch die Formulierung: „Nur relevante textbasierte Daten werden in die Cloud übertragen und während der Übertragung verschlüsselt.“ Bedeutet „während der Übertragung verschlüsselt“ die standardmäßige TLS-Verschlüsselung? Rewind sieht gut aus, aber man muss ihm vertrauen können.
„Keine Cloud-Integrationen erforderlich. Alles funktioniert automatisch, ohne dass Sie mehrere Dienste wie Gmail, Dropbox oder Slack verbinden müssen.“
In den Details der offiziellen Datenschutzerklärung unter https://www.rewind.ai/privacy steht jedoch:
„[Erfasste Daten:] Von OpenAI erzeugte Informationen. Als Teil der OpenAI-Integration von Rewind AI können wir auch von OpenAI erzeugte Ausgaben erfassen, darunter Zusammenfassungen von Transkriptionen von Audioaufnahmen und andere durch die OpenAI-Integration erzeugte Daten.“
Bedeutet das also: „Cloud-Integrationen sind nicht erforderlich“, aber mein Audio wird mit OpenAI geteilt?
Außerdem steht unter https://www.rewind.ai/privacy-first: „Was passiert, wenn Sie in Rewind suchen? Alle Aufzeichnungsdaten bleiben lokal.“
Ich weiß nicht, was von beidem gilt. Ich würde Rewind gern vertrauen, aber die Widersprüche in der Erklärung, wie Nutzerdaten verarbeitet werden, machen mich zögerlich.