- Zum einjährigen Jubiläum der aktuell veröffentlichten Version hat Spliit, eine Open-Source-App zum Aufteilen von Ausgaben, zur betrieblichen Transparenz die Nutzungs-, Kosten- und Spendendaten der vergangenen 12 Monate veröffentlicht
- Es gab 152.000 Besuche, und die wöchentlichen Besuche stiegen von etwa 200 auf 5.000 bis 6.000; eine Absprungrate von 33 % zeigt, dass Nutzer über den Home-Screen hinaus tatsächlich aktiv werden
- Zum Zeitpunkt der Veröffentlichung hatten Nutzer fast 15.000 Gruppen und 162.000 Ausgaben erstellt; seit Januar 2024 kommen pro Woche etwa 300 Gruppen und 2.000 Ausgaben hinzu
- Die Betriebskosten liegen bei rund 115 US-Dollar pro Monat, wobei der Großteil auf das Hosting der Datenbank entfällt; die weltweite Nutzung macht die Datenbankauslastung zum zentralen Engpass bei der Kostenoptimierung
- Spliit bleibt kostenlos und ist bei den Einnahmen auf GitHub Sponsors und Stripe-Spenden angewiesen; die Spenden decken die Gesamtkosten noch nicht vollständig, kommen ihnen aber sehr nahe
Die Größenordnung der Nutzung von Spliit
- Spliit wurde zwar vor einigen Jahren entwickelt, aber die derzeit nutzbare Version ist erst seit einem Jahr öffentlich verfügbar
- Die Daten zu Nutzung, Kosten und Spenden wurden veröffentlicht, nachdem ein GitHub-Nutzer eine Offenlegung im Sinne der Transparenz vorgeschlagen hatte
- In den vergangenen 12 Monaten verzeichnete Spliit 152.000 Besuche
- Anfangs waren es pro Woche etwa 200 Besuche
- Inzwischen gibt es konstant 5.000 bis 6.000 Besuche pro Woche
- Die Absprungrate liegt bei 33 %
- Die meisten Besucher verlassen die Seite also nicht, nachdem sie nur die Startseite gesehen haben
- Sie führen weitere Aktionen aus, etwa einer Gruppe beitreten, eine Ausgabe anlegen oder einen Blogbeitrag lesen
Geteilte Links und Zugriffsquellen
- Von den 152.000 Besuchern nutzten mindestens 29.000 Personen einen geteilten Link
- Der typische Nutzungsablauf ist, dass eine Person eine Gruppe erstellt und anschließend den Link mit den Teilnehmern teilt
- Viele Besucher kommen auch über Reddit
- Dort wird Spliit in Beiträgen erwähnt, die nach Alternativen zu Splitwise suchen
- Die Länder mit den meisten Besuchern sind Germany, United States, India
- Warum Spliit dort stärker genutzt wird, ist nicht bekannt
Gruppen und Ausgaben, die Nutzer erstellen
- Die wichtigsten Kernaktionen in Spliit sind das Erstellen von Gruppen und das Hinzufügen von Ausgaben
- Zum Zeitpunkt des Beitrags hatten Nutzer fast 15.000 Gruppen erstellt und insgesamt 162.000 Ausgaben angelegt
- Seit Januar 2024 werden laut Tracking pro Woche etwa 300 Gruppen und 2.000 Ausgaben erstellt
- Die Verteilung der Ausgaben pro Gruppe zeigt, dass mindestens 4.600 Gruppen überhaupt keine Ausgaben enthalten und vermutlich zum Testen der App erstellt wurden
- Von den übrigen rund 10.000 Gruppen enthält die Hälfte mehr als 5 Ausgaben
Monatliche Betriebskosten
- Der Betrieb von Spliit kostet rund 115 US-Dollar pro Monat
- Der Großteil der Kosten entfällt auf Datenbank-Hosting
- Die Datenbank wird bei Vercel gehostet
- Die Preisberechnung basiert auf der gesamten monatlichen Lesezeit der Datenbank
- Schreibkosten fallen fast nicht an
- Da Spliit weltweit genutzt wird, ist die Datenbank fast den ganzen Monat über in Gebrauch
- Die Datenbankkosten sind ein Bereich, den man verbessern möchte; möglicherweise gibt es für den Anwendungsfall von Spliit günstigere Datenbankanbieter
Das Prinzip der kostenlosen Nutzung und Spenden
- Das Geschäftsmodell von Spliit besteht darin, als Open-Source-Projekt erhalten zu bleiben, und die App soll auch künftig kostenlos nutzbar sein
- Künftig könnte es Premium-Funktionen geben, aber nicht in einer Form, die die normale Nutzung der App einschränkt
- Derzeit sind Spenden die einzige Einnahmequelle von Spliit
- Im ersten Monat spendete jemand 70 US-Dollar, danach gab es Nutzer, die 5 oder 20 US-Dollar spendeten
- Die Spenden decken bislang noch nicht die gesamten Projektkosten, kommen den Kosten aber bereits recht nahe
Warum es eine Spendenfunktion gibt
- Spenden sind für den Betrieb von Spliit nicht zwingend erforderlich
- Der Betreiber hat einen Vollzeitjob und ein ausreichendes Einkommen zum Leben
- Er ist damit zufrieden, einen Teil der Kosten selbst für die Community zu tragen
- Es gibt zwei Gründe, warum die Spendenfunktion hinzugefügt wurde
- Mehrere Nutzer baten um eine Möglichkeit, sich zu revanchieren, weil ihnen das Projekt gefällt
- Falls der Betreiber das Projekt eines Tages verlässt, soll die Community es ohne finanzielle Probleme weiterführen können
Wartungsaufwand und Beiträge aus der Community
- Der Betreiber investiert etwa 5 bis 10 Stunden pro Monat in Spliit
- Die meisten neuen Funktionen, die in den vergangenen Monaten zur App hinzugekommen sind, wurden nicht vom Betreiber, sondern von Beitragenden aus der Community entwickelt
- Die Zeit des Betreibers fließt hauptsächlich in das Projektmanagement
- In den issues verwaltet er Funktionsvorschläge, Bug-Reports und Fragen
- Er prüft und testet pull requests
- Er rollt neue Funktionen aus, damit alle Nutzer darauf zugreifen können
- In Spliit fließt viel Zeit, doch ein beträchtlicher Teil davon wird von anderen Beitragenden geleistet
Künftige Transparenz-Updates
- Spliit deckt mit Spenden inzwischen den Großteil der Hosting-Kosten; den verbleibenden Fehlbetrag trägt der Betreiber jeden Monat selbst
- Auch künftig sollen regelmäßig Transparenz-Updates zum Projektfortschritt und zur Finanzierung veröffentlicht werden
- Rückfragen sind an zwei Stellen möglich
1 Kommentare
Hacker-News-Kommentare
Ich frage mich bei solchen Einsatzzwecken immer, was alle als Datenbank verwenden. Ich mag SQLite sehr, aber bei Apps bevorzuge ich inzwischen meistens, dass sie getrennt und möglichst zustandslos sind.
Fast immer sind die Daten das Wichtigste, daher sollte man die App-Infrastruktur ohne große Sorgen beliebig skalieren, austauschen oder wegwerfen können.
Ich habe auch über einen Postgres-VPS nachgedacht, nutze aber neon.tech besser als erwartet. Besonders die GUI und das Branching fand ich gut.
Mit zunehmendem Alter und weniger Zeit werden mir Geschwindigkeit und Komfort wichtiger als mein antrainierter Spartrieb. Eine SaaS-Datenbank hat die Arbeit beschleunigt, aber monatliche Rechnungen und Schwankungen gefallen mir weiterhin nicht.
Wenn du die App wegwirfst und woanders deployest, holt Litestream die Daten wieder zurück, und alles läuft weiter, als wäre nichts passiert.
Am Anfang dieses Artikels zeige ich eine Demo, in der ich Litestream an meine App anbinde, die Heroku-Instanz wegwerfe und eine neue Instanz auf Fly.io erneut deploye. Litestream verschiebt alle Daten in das neue Deployment: https://mtlynch.io/litestream/
Mir ist nicht ganz klar, was man antreffen sollte, das die Kapazität eines kleinen VPS sprengt.
Ein eigener VPS für die Datenbank ergibt Sinn, aber wenn Requests angemessen gecacht werden, hält das bei nicht-kritischen Diensten durch; man muss nur die Backups robuster machen.
Besonders das dauerhafte Aktuellhalten, die Sicherheit und die korrekte Konfiguration sind das Problem. Die Ersteinrichtung ist leicht, aber danach wird es entscheidend; ich frage mich, wie man das heutzutage üblicherweise handhabt.
Ich habe die App ausprobiert und fand es großartig, dass keine Kontoerstellung nötig ist. Man bekommt einen privaten Link und teilt ihn mit der Gruppe; wer den Link öffnet, wählt aus, wer er ist, und „loggt sich“ so ein.
Natürlich kann man sich als anderes Mitglied einloggen und das System missbrauchen, aber es wirkt wie ein Kompromiss, den der Entwickler in Kenntnis seiner Nutzerschaft zugunsten reibungsloser Bedienbarkeit gewählt hat. Sauber.
Davon inspiriert baue ich eine App, mit der mein Buchclub eine „Wahl“ für das nächste Buch durchführen kann. Ich möchte mehrere Abstimmungsverfahren unterstützen, etwa Rangwahl, Zustimmungsvoting, Score Voting und Mehrheitswahl.
[0] https://www.when2meet.com/
Zur Frage der Kostensenkung: Wenn man das auf einem einzelnen Linux-VPS betreibt, dürfte man auf 5 bis 10 Dollar pro Monat kommen.
Interessant ist, dass die Wachstumskurve linear ist. Die App hat eindeutig eine gewisse Traction und auch einen viralen Charakter, aber warum wächst sie nicht exponentiell?
In Wirklichkeit wären es wohl etwa 100 Dollar, was ehrlich gesagt ziemlich überdimensioniert ist. Trotzdem ist mein Traffic deutlich größer als im Blog beschrieben.
Mit Verbesserungen an der Architektur ließen sich die Kosten vermutlich senken.
Etwa in der Mitte des Artikels wird als anderes Modell, das besser zu solchen Wachstumsmustern passt, logistisches Wachstum vorgestellt. Nach frühem starkem Wachstum folgt eine lineare Wachstumsphase, und schließlich flacht es beim Erreichen der „Kapazitätsgrenze“ oder „Marktsättigung“ ab.
Ich hoste eine ähnliche Anwendung bei Anbietern wie netcup und Hetzner für 3 Dollar im Monat, und selbst als sie auf HN war, hat sie problemlos über 10.000 Requests pro Stunde verarbeitet.
Unabhängig von den konkreten Zahlen frage ich mich immer, wie man bei solchen Projekten die laufenden Kosten deckt.
Eine Idee, die mich interessiert hat, ist, das dezentral zu lösen. Es fließt Geld in das Projekt, und wenn es die monatliche Rechnung nicht bezahlen kann, stirbt es.
Wenn genug überschüssige Mittel eingehen, könnte man wohl US-Staatsanleihen mit passender Laufzeit kaufen und diese mit der Zeit aufbrauchen.
Früher hätte das Automatisierung erfordert, aber vielleicht kann in naher Zukunft ein begrenzter AI-Agent als Server fungieren und man lässt ihn einfach seine Arbeit erledigen.
Pay-as-you-go-Modelle sind gut, wenn auch der Umsatz mit der Nutzung steigt. Für meine Projekte hätte ich gern einen Tarif, bei dem die Fixkosten zwar höher sind, das Risiko aber nur in der Verfügbarkeit und nicht in den Kosten liegt.
Deshalb passt der Umsatz bei nutzungsbasierter Abrechnung oft nicht gut zu den Erwartungen, und gestaffelte Tarife gewinnen am Markt leicht, weil sie mehr Geld abschöpfen.
Eine Ausnahme scheinen mir Dinge wie Dateispeicher zu sein, bei denen Menschen eher unterschätzen, wie viel Kapazität sie brauchen.
Ich mag spliit wirklich sehr und nutze es regelmäßig, mehrmals pro Woche.
Was mich wahnsinnig macht: Bei langsamen Mobilverbindungen funktioniert es wirklich schlecht. Ich würde gern Local-first- oder Offline-first-Unterstützung hinzufügen, weiß aber, dass das eine große Änderung wäre.
Trotzdem würde es schon ziemlich helfen, Seiten wie die Seite zum Hinzufügen von Ausgaben zu cachen.
Die Idee ist gut, aber anhand der Traffic-Zahlen würde vermutlich ein 4-Dollar-DigitalOcean-Droplet dasselbe Ergebnis liefern.
Durch die Nutzung von Vercel wurden über 1.000 Dollar verbrannt. Vielleicht bin ich einfach alt geworden, aber diese Logik verstehe ich nicht.
Wenn man einmal einen einfachen VPS einrichtet, bekommt man dasselbe Ergebnis, und die Kosten bleiben neutral; meine kleinen kostenlosen Apps betreibe ich auch so.
Vermutlich sind 100 Dollar im Monat für den Autor keine große Belastung, oder er ist in einer Lage, in der er diesen Betrag gern für Bequemlichkeit zahlt.
Die Webhosting-Kosten sind praktisch nahezu null. Der Großteil der Kosten kommt von der Datenbank.
Eine wirklich hervorragende App. Es war gut, die Kostenaufstellung zu sehen.
Wenn Banken vernünftig wären, wäre diese Funktion auf Basis von ACH/Zelle/FedNow längst eine Standardfunktion in Banking-Apps.
Der Organisator sollte in der Banking-App eine Gruppe erstellen und Nutzer mit Konten bei unterschiedlichen Banken einladen können.
Zahlungsanfragen sollten mit einem Klick erledigt sein, und man sollte nicht mehr manuell prüfen müssen, ob Geld in Cash App, auf dem Bankkonto oder bei Venmo angekommen ist, und anschließend Ausgaben in einer Drittanbieter-App abhaken müssen.
Was gebraucht wird, ist eine Integration mit Zahlungsanbietern. Man sollte sofort per ACH oder Kreditkarte zahlen können.
Das könnte zugleich eine Monetarisierungsoption sein.
Ich denke, es ist besser, Open Source und kostenlos zu bleiben und eine praktische App für Bargeldtransaktionen zu sein.
Mit serverlosen Datenbanklösungen wie Supabase oder NeonDB ließe sich vermutlich ziemlich viel Geld sparen.