Open-Source-Stripe-Alternative „Lago“ erhält 22 Mio. Dollar Finanzierung

 (techcrunch.com)
3 Punkte von GN⁺ 2024-04-08 | 2 Kommentare | Auf WhatsApp teilen
  • Das in Paris ansässige Lago gab zum offiziellen Launch seinen Wandel zu einer Open-Source-Billing-Plattform für Entwickler bekannt und hat in zwei Runden rund 22 Mio. Dollar ($22m) eingesammelt
  • Die jüngste Series A über 15 Mio. Dollar wurde von FirstMark angeführt, die frühere Seed-Runde über 7 Mio. Dollar von SignalFire; beteiligt waren außerdem Y Combinator, New Wave, Script sowie einzelne Angel-Investoren
  • Das Team wollte ursprünglich ein „Zapier“ für Marketing-Teams bauen, pivotierte jedoch zu einer Billing-Plattform, nachdem ein Hacker-News-Beitrag über Billing-Probleme von Entwicklern große Resonanz ausgelöst hatte
  • Mistral.ai, Together.ai und Juni kamen als frühe Kunden in der privaten Beta hinzu; Lago zielt auf Startups mit Abonnement-, nutzungsbasierten und hybriden Preismodellen
  • In einem Markt mit Stripe, Adyen, Salesforce, Zoho, Paddle und anderen setzt Lago auf Skalierbarkeit und individuell angepasste Billing-Implementierungen als Differenzierungsmerkmal

Offizieller Launch und Finanzierungsstruktur

  • Das in Paris ansässige Startup Lago gab zum offiziellen Launch seiner Open-Source-Billing-Plattform bekannt, insgesamt 22 Mio. Dollar an Finanzierung eingesammelt zu haben
  • Die Finanzierung besteht aus zwei Runden
    • Die jüngste Series A über 15 Mio. Dollar wurde von FirstMark angeführt
    • Die frühere Seed-Runde über 7 Mio. Dollar wurde von SignalFire angeführt
  • Auch Y Combinator, New Wave und Script beteiligten sich als Investoren
  • Zu den Angel-Investoren zählen Meghan Gill, Head of Monetization bei MongoDB, Romain Huet, früher bei Stripe und zuständig für Developer Relations bei OpenAI, sowie Hugging-Face-CEO Clément Delangue
  • Laut Quellen liegt die Bewertung von Lago bei rund 100 Mio. Dollar

Private Beta und frühe Kunden

  • Vor dem offiziellen Launch lief Lago als private Beta
  • Zu den frühen Kunden gehören Startups wie Mistral.ai, Together.ai und Juni
  • Der Fokus liegt darauf, Entwicklern zu helfen, Billing-Systeme passend zu neuen Services selbst anzupassen
  • Die Plattform unterstützt dabei, Nutzungsdaten zu messen und Abonnements oder andere Preismodelle abzuwickeln

Pivot vom Marketing-Tool zur Billing-Plattform

  • Lago war ursprünglich nicht als Billing-Plattform geplant
  • Die Mitgründer Anh-Tho Chuong und Raffi Sarkissian gründeten das Unternehmen nach ihrer Zeit bei Qonto und traten der Y Combinator Summer 2021-Kohorte bei
  • Beim Eintritt in YC hatten sie noch kein Produkt; später entschieden sie sich für die Idee eines „Zapier“ für Marketing-Teams
  • In dem stark umkämpften Marketing-Tech-Markt gewann das frühe Produkt kaum Traktion
  • Um Aufmerksamkeit zu erzeugen, veröffentlichte Sarkissian auf Hacker News einen Beitrag über Billing-Probleme von Entwicklern
    • Der Titel lautete „Billing systems are a nightmare for engineers“
    • Das knüpfte an seine Erfahrung an, bei Qonto ein Produkt zur Lösung von Billing-Problemen entwickelt zu haben
  • Als viele Nutzer ihre eigenen Billing-Probleme teilten, richtete Lago seinen Fokus darauf aus, Billing-Probleme für Entwickler zu lösen

Open-Source-Strategie für komplexes Billing

  • Für einfache Preis- und Billing-Modelle gibt es bereits viele Lösungen, doch für komplexes Billing sieht Lago noch keine ausreichenden Antworten
  • Unternehmen, die KI-basierte Produkte entwickeln, suchen nach tragfähigen Geschäftsmodellen und ziehen häufig hybride Ansätze in Betracht, die feste Abonnements mit nutzungsbasierten Preisen kombinieren
  • Solche Modelle benötigen Tools, die sich in die von Entwicklern gebauten Produkte integrieren und Nutzungsdaten erkennen und anwenden können
  • Viele Unternehmen bauen wie Qonto eigene Billing-Systeme, doch Entwickler mögen diese Arbeit nicht, und die Kosten für dedizierte Engineers sind hoch
  • Timothée Lacroix, Mitgründer und CTO von Mistral.ai, nannte als Grund für die Wahl von Lago den Glauben an das Open-Source-Ökosystem und erklärte, Lago habe geholfen, mit dem Release-Tempo Schritt zu halten und sich auf das Kerngeschäft zu konzentrieren

Wettbewerb und nächste Expansionsfelder

  • Im Billing-Markt gibt es bereits Lösungen großer Technologieunternehmen wie Stripe, Adyen, Salesforce, Zoho und Paddle
  • Es gibt auch bestehende Anbieter mit Open-Source-Ansatz
    • FOSSBilling
    • ChargeBee
    • Kill Bill
    • jBilling von AppDirect
    • Open Source Billing
  • Lago sieht trotz des starken Wettbewerbs Chancen in Skalierbarkeit und auf Startups zugeschnittenen Billing-Implementierungen
  • Künftig prüft das Unternehmen neben dem Ausbau des bestehenden Geschäfts zwei Bereiche
    • Datenanalyse, die an die ursprüngliche Marketing-Idee anknüpft: Einblicke darin, was Kunden konsumieren und bezahlen und wie ihre Zahlungsmuster aussehen
    • Den Zahlungsbereich als Gegenstück zum Billing
  • Es ist unwahrscheinlich, dass Lago einen eigenen Payment-Stack baut; wahrscheinlicher ist ein Fokus auf Payment-Orchestrierung, damit Nutzer die gewünschten Payment-Tools verwenden und diese gut in die Billing-Plattform integrieren können

Verwandte Beiträge

2 Kommentare

 
xguru 2024-04-08

Lago hat den Vergleich mit Stripe ziemlich aggressiv betrieben … und wie erwartet auch viel Investment eingesammelt.
Sie haben auch Texte wie Was Stripe wirklich kostet: Ein Leitfaden für Einsteiger veröffentlicht.

Trotzdem wirkt es irgendwie nicht ganz passend, dass eine Billing-API Open Source ist.
 
GN⁺ 2024-04-08
Meinungen auf Hacker News

  • Ich wollte es für ein neues SaaS-Produkt ausprobieren, war aber überrascht, dass die Pläne erst bei 3.000 $ pro Monat anfangen.
    Das scheint in die falsche Richtung zu gehen. Kleine Teams wie meines wollen kein Self-Hosting, sondern eine Managed Solution. Große Unternehmen haben die nötige Größe und können sich eher Self-Hosting leisten.

    • Ich verstehe, was du meinst, aber diese Strategie könnte funktionieren. In meinem früheren Unternehmen sind wir anfangs mit Stripe gestartet; weil der Umsatz gering war, fielen kaum Kosten an und die Integration war einfach.
      Als das Transaktionsvolumen nach ein paar Jahren größer wurde, wollten wir den Vertrag neu verhandeln. Wenn wir damals auf Lago hätten neu integrieren können, wäre das bei der Verlängerung des Stripe-Vertrags ein Verhandlungshebel gewesen. Wir zahlten 30.000 $ pro Monat an Stripe-Gebühren, daher hätte eine Alternative für 3.000 $ pro Monat durchaus lohnend sein können. Unsere Situation war etwas anders, weil es bei uns nicht um SaaS-Abrechnung, sondern um Retail ging, aber ich sehe Fälle, in denen es finanziell Sinn ergibt.
    • In dieselbe Falle sind wir auch getappt. Nutzungsbasierte Abrechnung ist für uns ein großer Schmerzpunkt, daher hatten wir große Hoffnungen in Lago gesetzt, wollten aber unsere Infrastruktur nicht selbst betreiben, wenn wir das auslagern können.
      Wir haben mit etwa fünf Anbietern von APIs für nutzungsbasierte Abrechnung gesprochen, aber realistisch hatte fast niemand Interesse am Markt unter 1.000 $ pro Monat, in dem wir während unserer Wachstumsphase im nächsten Jahr bleiben werden. Außerdem werben Lago und andere Anbieter zwar mit „kein Revenue Share“, nennen aber immer Preise als Prozentsatz des Umsatzes. Technisch gesehen ist es kein Revenue Share, aber die Kosten steigen nahezu linear mit dem Umsatz.
    • Es geht nur dann in die falsche Richtung, wenn die Strategie darauf abzielt, das untere Marktsegment zu bedienen. Danach sieht es hier nicht aus.
    • Dieser Preis deutet darauf hin, dass sie große Stripe-Kunden anvisieren, die monatlich mehr als 3.000 $ an Gebühren zahlen.
      Wenn die Preisstrategie darin besteht, kleine, supportintensive und wenig profitable Kunden zu meiden, Stripe mit diesen Kunden Verluste machen zu lassen und dann nur die guten Kunden abzugreifen, die bei Stripe bereits gewachsen sind, ist das clever.
    • Der beabsichtigte Markt könnte so etwas wie mittelgroße Forellen sein.

  • Ich glaube, es wird schwer, an Entwickler zu verkaufen. Entwickler geben kein Geld aus und wollen alles selbst bauen, selbst wenn die Opportunitätskosten zehnmal so hoch sind.
    Und sobald man irgendwie versucht, Geld damit zu verdienen, gibt es wie bei Redis eine große Abwanderung wegen „Verrats“. Ich weiß das, weil ich selbst so ein Entwickler bin.

    • Nutzungsbasierte Abrechnung ist schwierig. Ich habe Lago ziemlich ernsthaft geprüft, aber für mein B2C-API-Geschäft passte es nicht.
      Ich brauchte unbedingt ein Kundenportal, aber das war eine Premium-Funktion, und Premium kostete mindestens 1.500 $ pro Monat. Bei meinem Umsatz war das schwer zu rechtfertigen. Allerdings vermeidet Lago bewusst eine umsatzprozentuale Abrechnung, daher müssen sie eine hohe Grundgebühr verlangen. Stripe Billing berechnet prozentual, und bei einem wachsenden Geschäft ist es nur eine Frage der Zeit, bis die Stripe-Rechnung 1.500 $ übersteigt.
      Ich habe mir auch die nutzungsbasierte Abrechnung von Stripe Billing angesehen, aber sie erfüllte meine Anforderungen nicht. Für Pauschalabrechnung nutze ich Stripe Billing.
      Meine genaue Anforderung ist, API-Credits als im Abo enthaltene Prepaid-Credits verkaufen zu wollen. Wenn sich ein Nutzer zum Beispiel für 10 $ Credits pro Monat anmeldet, zahlt er zuerst 10 $ und verbraucht dann Credits in diesem Gegenwert. Stripe Billing unterstützt bei nutzungsbasierter Abrechnung keine Vorausberechnung, sondern stellt erst nach Ende des Abrechnungszeitraums eine Rechnung. Manche Nutzer missbrauchen das System, indem sie kündigen und nicht zahlen; deshalb passt es für mich nicht. Soweit ich mich erinnere, unterstützte Lago Vorausberechnung.
      Außerdem wollte ich Abo-Credits und Prepaid-Credits frei mischen können. Wenn Nutzer in einem Monat ihr Kontingent überschreiten, bevorzugen sie eine einmalige Aufladung gegenüber einem Upgrade auf den höchsten Tarif. Ich muss auch steuern können, welche Credits zuerst verbraucht werden, und sowohl Stripe Billing als auch Lago hatten hier Probleme.
      Bei den Zahlungsmethoden wollte ich möglichst viele unterstützen, insbesondere chinesische Wallets wie Alipay und WeChat für Prepaid-Credits. Lago hatte nicht vor, das umzusetzen, und ich habe sogar halb ernsthaft erwogen, es direkt in Lago zu implementieren. Im B2B-Bereich sind WeChat und Alipay möglicherweise nicht so wichtig.
      Außerdem mag ich Code mit sehr engmaschigen Regressionstests, und dank der Test-Clock-Funktion ist Stripe Billing Lago in dieser Hinsicht weit voraus. Lago hat keine Funktion, um für Tests des Subscription-Lebenszyklus die Zeit vorzuspringen. Wenn man dem Produkt vertraut, kann man einfach erwarten, die richtigen Callbacks zur richtigen Zeit zu erhalten; dann ist das vielleicht weniger wichtig.
      Trotzdem habe ich gesehen, dass die Lago-Entwickler sich auf Slack Zeit nehmen, selbst sehr tiefgehende technische Fragen zu beantworten. Wenn ich ein B2B-Startup betreiben würde, vor allem zu einem Zeitpunkt, an dem man viele Fälle von gesperrten Stripe-Konten sieht, hätte ich wahrscheinlich versucht, Lago irgendwie passend zu machen.
    • Das ist ein klassischer typical mind fallacy. Ich bin auch Entwickler, zahle aber gerne für Dinge, die mir Zeit sparen.
      Und genau das ist, glaube ich, die Kernhypothese von Lago: Entwickler wollen Open-Source-Abrechnungssoftware, die sie bei Bedarf selbst anpassen können, statt von einem proprietären Anbieter wie Stripe abhängig zu sein. So abwegig ist der Gedanke nicht.
    • Ich bin kein Entwickler, der kein Geld ausgibt. Ich glaube, wirtschaftliches Denken ist ein grundlegender Bestandteil von Engineering. Wenn man nicht wirtschaftlich denkt, tut man vielleicht irgendetwas, aber es ist möglicherweise kein Engineering.
      Wie im Nachbarkommentar gesagt: Für Dinge, die Wert schaffen und Zeit sparen, zahle ich gerne. Ich bin nie auch nur auf die Idee gekommen, ein eigenes Abrechnungssystem zu bauen.
    • Wenn sie dieses Problem nicht bereits gelöst hätten, hätten sie vermutlich nicht so viel Investment bekommen.

  • Vielleicht bin ich einfach alt geworden und mein Gefühl dafür, was Open Source bedeutet, hat sich nicht an die veränderte Realität angepasst, aber wenn Open Source und „22 Mio. $ Investment“ in einem Satz stehen, denke ich sofort: „Was soll daran Open Source sein?“

    • Gibt es einen Leitfaden dafür, wie man Open-Source-Software entwickelt, ohne sie zu monetarisieren? Oder ist es nicht mehr wirklich Open Source, sobald man VC-Geld annimmt?
      Diese Stimmung habe ich oft gesehen, besonders auch bei Open-Source-Veteranen wie Rich Harris. Ironischerweise bekommt er inzwischen sein Gehalt aus VC-Geld. Einerseits möchte ich auch darüber schimpfen und sagen, Menschen sollten offene Software einfach aus Freude am Bauen und Teilen entwickeln. Aber in der realen Welt zu leben kostet viel Geld, und zu erwarten, dass jemand Software, die ich nützlich finde und mit der ich vielleicht sogar direkt Geld verdiene, nachts und am Wochenende baut und dafür nur GitHub-Stars bekommt, wirkt unproduktiv und unfair.
    • Zustimmung, aber gleichzeitig weiß ich nicht, was die Alternative sein soll. Einfach in der Freizeit bauen, um ein paar Spenden betteln und $corporate erlauben, es als Service zu verkaufen, ohne etwas zurückzugeben?
      Im Kontext von Lago sehe ich den Nutzen von Open Source außer PR und Sympathie bei Entwicklern nicht wirklich. Wenn man heute etwas als Open Source baut, steckt man in einer Zwickmühle; wenn das die Zukunft ist, die eine längere Lebensdauer und besseren Support bringt, muss man sie wohl akzeptieren.
    • Korrigiert mich bitte, wenn ich falschliege, aber funktionieren SUSE, Red Hat und Databricks nicht auch so? Ich verstehe das als Modell, bei dem nützliche Open-Source-Tools bereitgestellt werden und über Services darum herum das Geld verdient wird, um die Entwicklung fortzuführen.
    • Gemeint ist „Open Source, bis der VC den Monetarisierungsdruck erhöht“. Danach wechselt man zu einer restriktiveren Lizenz und ruiniert damit die bisherigen Beitragenden und die gesamte Community.
    • Ich will nicht gegen dieses Bauchgefühl von „Was soll daran Open Source sein?“ ankämpfen, aber ich kann erklären, warum es sich so anfühlt.
      Als Open Source Mitte der 1970er begann, war der Geist dahinter, Software kostenlos zu teilen. Das Geld kam in Form von Universitäts- oder Unternehmensforschungszuschüssen; ein Geschäftsmodell gab es nicht. 1998 kam dann ernsthaft Geld ins Spiel, als Red Hat, MySQL und andere bezahlten Support und Services auf freie Software aufsetzten. Ab Mitte der 2000er wurde die Idee, mit Open Source Geld zu verdienen, durch Cloud Computing verbreitet. Bei SaaS wissen oder kümmern sich Nutzer oft nicht darum, ob die Innereien Open Source oder proprietäre Software sind, sodass Open Source auf dasselbe Spielfeld kam.
      Es gibt mehrere Gründe, warum VCs Open Source mögen. Ich bin Investor mit Hintergrund als Machine-Learning-Ingenieur, und persönlich habe ich auch nostalgische Erinnerungen daran, an der Uni großartige Open-Source-Projekte wie spaCy genutzt zu haben, und ich teile Werte wie Community, Transparenz und Zurückgeben. Gleichzeitig ist es die Aufgabe eines VC, Geld zu verdienen.
      Closed-Source-Unternehmen geben viel Geld für Sales und Marketing aus. Entwickler mögen es in der Regel nicht, etwas verkauft zu bekommen; sie wollen selbst wählen, statt überzeugt zu werden. Wenn ein Unternehmen die Herzen der Entwickler gewinnt, wird die Software in den Beschaffungsprozess hineingezogen, ohne Millionen für Sales und Marketing auszugeben, wodurch das Geschäftsmodell effizienter wird. Auch die Verteidigungsfähigkeit ist stärker. Große Unternehmen können viel Geld in Vertriebsteams im Anzug stecken, um Produkte zu verkaufen, aber die Liebe der Entwickler kann man nicht kaufen. Dafür braucht es eine hervorragende Developer Experience und gute Developer Relations.
      Allerdings ist es deutlich schwieriger, mit Open Source Geld zu verdienen als mit SaaS. Bei SaaS spricht man von Product-Market-Fit. Wenn man fünf oder mehr Kunden findet, die es auf dieselbe Weise nutzen, auf dieselbe Weise kaufen und denselben Wert daraus ziehen, schafft man Vorhersagbarkeit; dann geben VCs Geld und man skaliert den Vertrieb. Bei Open Source wird dieses Problem dreifach. Project-Community-Fit sieht man an GitHub Stars, Product-Market-Fit an Downloads und Value-Market-Fit am Umsatz. Außerdem kann der Käufer jemand anderes sein als der Entwickler oder Nutzer. Die meisten großartigen Open-Source-Produkte scheitern am Value-Market-Fit.
      Die meisten Gründer von Open-Source-Unternehmen scheitern daran, Wert abzuschöpfen. Entweder, weil es zu schwer ist, oder weil sie die Monetarisierung aufschieben, da Open Source sich nach „kostenloser Software“ anfühlen soll. Und wenn sie mit der Monetarisierung beginnen, ist es zu spät. Wenn man jahrelang die Milch kostenlos bekommen hat, warum sollte man dann die Kuh kaufen? Ein weiterer Grund ist, dass sie nicht wissen, wie. Die typischen Wege, mit Open Source Geld zu verdienen, sind der Verkauf von Support und Services, Open Core mit proprietären Funktionen sowie SaaS durch Hosting und Tools. Beispiele sind Red Hat, Confluent, Elastic und Databricks.
      Sehr vereinfacht, gemessen an erfolgreichen Open-Source-Unternehmen: Die kostenlose Version sollte alles enthalten, was ein einzelner Entwickler braucht, um seine Arbeit zu erledigen. Das kostenpflichtige Produkt sollte zusätzliche Funktionen bieten, die ein Team braucht, um seine Arbeit zu erledigen.
      Ich mag Open Source, und es ist traurig zu sehen, wie sehr kluge Gründer und zahllose Beitragende mit Leidenschaft daran arbeiten und trotzdem nicht skalieren und nicht belohnt werden. Kommerzialisierung hilft dabei, ist aber wirklich schwierig. Menschen, die zu Open Source beitragen und es erschaffen, legen Wert auf Community und wollen Dinge kostenlos weitergeben; deshalb fühlt sich schon der Gedanke, Geld zu verdienen, unangenehm an. Wenn es unangenehm wird, kehren Menschen dorthin zurück, wo sie sich auskennen, und für die meisten Engineers ist das Coding. So entstehen großartige Open-Source-Software mit vielen coolen Features und Gründer, die die Monetarisierung zu lange aufschieben. Wenn irgendwann der Punkt ohne Wiederkehr überschritten ist, stirbt wieder ein vielversprechendes Unternehmen; und egal wie großartig das Produkt ist, Investoren investieren nicht, wenn sie ihr Geld nicht zurückbekommen können.

  • Wenn man weiterhin Bearbeitungsgebühren zahlen muss, wo liegt dann der Vorteil?
    Wenn man einen eigenen Payment-Stack und PCI-Compliance aufrechterhalten muss, wirkt das wie eine enorme Ablenkung.

    • Das ist keine Alternative zum eigentlichen Payment-Netzwerk von Stripe, sondern eine Alternative zu Stripe Billing. In der Praxis nutzt man mit Lago weiterhin Stripe oder ein ähnliches Zahlungsmittel: https://docs.getlago.com/guide/payments/overview
      Wiederkehrende Zahlungen, Rechnungen, anteilig berechnete Tarifwechsel und Edge Cases bei nutzungsbasierter Abrechnung nachzuverfolgen, ist schwierig. Und die Stripe-Billing-API ist in vielen Fällen auch nicht besonders elegant. Es ist erfreulich, dass in diesem Bereich eine neue Schicht entsteht.
    • Tatsächlich ist PCI-Compliance zu einem großen Teil ein gelöstes Problem. Wenn man etwas wie https://verygoodsecurity.com nutzt und vor Lago sowie dem Self-Hosting einen Proxy setzt, kann man in die einfachste PCI-Compliance-Stufe fallen.
      Zur Einordnung: Ich habe Very Good Security gegründet und war dort acht Jahre lang CEO.
    • Und trotzdem werden die Leute sagen, Blockchain habe keinen Anwendungsfall.

  • Es gibt ein ähnliches, in Rust geschriebenes Open-Source-Projekt: https://hyperswitch.io
    Lago ist in Ruby geschrieben, und ich habe auch ein paar andere Open-Source-Abrechnungssysteme gefunden, die in Java geschrieben sind. Kennt jemand eines in Node.js?

    • Warum ist es wichtig, in welcher Sprache ein Dienst geschrieben ist? Man interagiert doch wahrscheinlich nicht direkt mit der Codebasis von Stripe oder Lago.
    • Hyperswitch sieht so aus, als würde es nur Zahlungen abwickeln, nicht Billing.

  • Paris scheint wirklich ein heißer Ort zu sein, um neue Fintech-Startups hervorzubringen.

    • Stimme völlig zu, aber die Erfolgsbilanz war nicht gut, und ein Teil davon lässt sich durch EU-Förderung erklären. Nicht, dass EU-Förderung an sich schlecht wäre, aber in Europa gibt es nicht genug hungrige Gründer, und angesichts des hohen Lebensstandards ist das leicht zu erklären. Das ist das Paradoxe daran.
      Umgekehrt gibt es in Frankreich auch Gegenbeispiele mit großartigen Ambitionen. Semmle [1] zum Beispiel wurde von GitHub für statische Repository-Analyse übernommen. Inria [2] ist ebenfalls großartig, aber das Problem ist nicht die Forschung, sondern wie man auf geschäftlicher Ebene mit US-Unternehmen konkurriert.
      [1] https://en.wikipedia.org/wiki/Semmle
      [2] https://www.inria.fr/en

  • Im GitHub-README verwenden sie das Drake-Meme.
    https://github.com/getlago/lago
    https://imgur.com/a/gsrhUXm
    Dass technische Dokumentation vermemt wird, hätte ich nicht erwartet … meine Güte.

    • Ich frage mich, ob du erst nach 2015 in die Branche gekommen bist. Selbst in sehr technischen Analysen, etwa den Jepsen Reports zur Bewertung technischer Behauptungen über Cassandra DB, waren zwischen den technischen Inhalten viele Memes. In Präsentationen gab es auch ständig Katzen- oder Hundefotos.
    • In technischer Dokumentation gibt es schon lange Memes in verschiedensten Formen. Sie sind harmlos und signalisieren Intelligenz und Gespür, deshalb freue ich mich darüber. Alles zu ernst zu nehmen, ist keine gute Sache.
    • Allerdings ist es seltsam, dass die Reihenfolge der Panels falsch ist.
    • Memes gibt es in technischer Dokumentation schon so lange, wie es Techniker und Dokumentation gibt.
    • Hast du in K&R noch nie Rekursion nachgeschlagen? Ich meine mich zu erinnern, dass Google sich früher auch an diesem Witz beteiligt hat.

  • Kennt jemand eine echte Alternative zu Stripe Payments? Stripe will nicht mit uns arbeiten und offenbar nur mit Closed-Source-Konkurrenten zusammenarbeiten, deshalb hängen wir an PayPal fest.

    • Du könntest https://mollie.com ausprobieren.
      Zur Einordnung: Ich arbeite dort.
    • Es gibt viele auf dem Markt. Allerdings haben sie jeweils Vor- und Nachteile, und die APIs sind wahrscheinlich schwieriger zu handhaben.

  • Das ist keine Stripe-Alternative.
    Billing, Rechnungen, Zahlungen, Berechtigungen und Abos sind alles unterschiedliche Dinge.

    • Tatsächlich beginnen wir mit Billing, und langfristig haben wir die Vision, ein open revenue hub zu werden. Die großen Schritte haben wir hier zusammengefasst: https://www.getlago.com/blog/lago-raises-22-millions
      Das bedeutet, dass wir eine offene Alternative für den gesamten RevOps-Bereich anbieten wollen. Statt in ein Closed-Source-Ökosystem wie Stripe einzusteigen, wollen wir ermöglichen, einen maßgeschneiderten Stack aufzubauen und mit einem „Best-of-Breed“-Ansatz Long-Tail-Tools, Use Cases und eigene Systeme anzubinden. Stripe hat 21 Produkte, und viele Gründer wissen nicht, dass sie nicht nur „Stripe Payments“ nutzen, sondern 3 bis 6 davon, die jeweils in der Regel einen Teil des Umsatzes abschöpfen.

  • Sie haben in der Series A 15 Mio. eingesammelt; die Bewertung wurde nicht bekannt gegeben, soll aber Gerüchten zufolge bei 100 Mio. liegen.
    Laut Crunchbase waren die 7 Mio. die Seed-Finanzierung aus dem Jahr 2023. Wenn man sich den letzten Absatz des verlinkten Artikels ansieht, scheint es nicht darum zu gehen, Stripe komplett zu ersetzen. So oder so ist es eine interessante Geschichte eines erfolgreichen Startup-Pivots, der mit einem leidenschaftlichen HN-Beitrag begann.

    • Wir konzentrieren uns zunächst darauf, eine Billing-Alternative zu einem der zentralen Dienste von Stripe zu bauen. Insbesondere entwickeln wir Billing für gemischte Abrechnungsmodelle oder nutzungsbasierte Preismodelle, also Bereiche, in denen Stripe schwach ist.