Der Code meines Startups, das nach 3 Jahren scheiterte, ist jetzt öffentlich

 (dylanhuang.com)
3 Punkte von GN⁺ 2024-12-18 | 1 Kommentare | Auf WhatsApp teilen
  • Konfig begann als Developer-Tools-Startup, das API-Integrationen vereinfachen sollte, und veröffentlicht nach 3 Jahren bis zur Einstellung nun die Codebasis mit Produktcode und Betriebsartefakten
  • Das Kernprodukt war ein SDK Generator, der aus OpenAPI-Spezifikationen Client-Bibliotheken erstellt; später wurde das Produkt um Dokumentation und eine interaktive API-Testumgebung erweitert
  • Es gab zwar Reaktionen von einigen Startup-Kunden, aber wegen der Schwierigkeit von Vertragsabschlüssen und des niedrigen Preisniveaus ließ sich daraus nur schwer ein Geschäft mit hyperhohem Wachstum machen
  • Danach erfolgte ein Pivot zu einem vertikalen B2B-SaaS-AI-Produkt, doch auch nach zahlreichen Interviews und Vertriebsprozessen ließ sich keine Marktresonanz (Traction) finden, die Vertrauen in ein großes Geschäft gerechtfertigt hätte
  • Das öffentliche Repository ist im Zustand zum Zeitpunkt der Schließung veröffentlicht und enthält ohne Aufräumen oder Korrekturen Produktcode, Pivot-Experimente, Sales-Skripte, Deployment-Konfigurationen und die Marketing-Website

Die API-Developer-Tools, die Konfig gebaut hat

  • Konfig war ein API-Developer-Tools-Startup, das Ende 2022 startete und sich darauf konzentrierte, den Umgang von Entwicklern mit APIs zu vereinfachen
  • Ziel war es, die Werkzeuge rund um SDK-Erzeugung, Dokumentation und Tests zu verbessern
  • Das Hauptprodukt war der SDK Generator
    • Er nimmt OpenAPI-Spezifikationen als Eingabe und erzeugt Client-Bibliotheken für mehrere Programmiersprachen
    • Später wurde das Angebot auf API-Dokumentationstools und eine interaktive API-Testumgebung ausgeweitet

Wachstumsgrenzen und AI-Pivot

  • Bei einigen Startup-Kunden gab es Traction, aber das führte nicht zu einem Geschäft mit hyperhohem Wachstum
  • Es war schwierig, mit potenziellen Kunden Verträge abzuschließen, und selbst bei nachweisbarem ROI war das Preisniveau zu niedrig
  • Nach dem Fortschritt bei generativer AI sah man die Chance, zuvor schwer lösbare Probleme anzugehen, und pivotierte zu einem vertikalen B2B-SaaS-AI-Produkt
  • Zu mehreren Ideen wurden Nutzerinterviews und Vertrieb durchgeführt, doch es fand sich keine Traction, die ausreichend Zuversicht gegeben hätte, dass daraus ein sehr großes Geschäft werden könnte

Ein Repository, veröffentlicht genau im Zustand der Schließung

  • Das öffentliche Repository ist konfig-dev/konfig
  • Das Repository wurde genau im Zustand der Unternehmensschließung veröffentlicht
    • Kein Aufräumen
    • Keine Überarbeitung
    • Keine Korrekturen
    • Die Codebasis zeigt ungefiltert den realen Zustand von Startup-Code

Wichtige Produkte aus 3 Jahren Entwicklung

Mitveröffentlichter Betriebs-Code und Experimente

Rückblick des Gründers

  • Dylan Huang verließ im März 2022 seinen Job, um sich ganz dem Startup zu widmen, und nahm die Herausforderung trotz des Risikos eines Scheiterns an
  • Er versteht dieses Scheitern als eine Erfahrung, die ihm mehr beigebracht hat als Erfolg
  • Als Nächstes will er neue Möglichkeiten erkunden, im Arbeitsmarkt nach einer passenden Rolle suchen und weiter lernen und wachsen
  • Auch die Herausforderung, eines Tages wieder selbst etwas zu bauen, hält er sich offen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-12-18
Hacker-News-Kommentare

  • Wenn man statt auf ein riesiges Geschäft mit „hyperrasantem Wachstum“ auf ein kleines Geschäft gezielt hätte, fragt man sich, wie viele großartige Nischenprodukte heute noch übrig wären

    • Das ist leicht gesagt, aber in der Praxis ist es wirklich schwer, weil man 3–5 Jahre lang praktisch ohne Gehalt durchhalten und dabei auf ein ähnliches Ergebnis wie bei einem finanzierten Unternehmen hoffen muss
      Damit ein Startup mit 2–3 Leuten in einem Industrieland überleben kann, muss es extrem viele Lizenzen für 10 Dollar im Monat verkaufen, und die Opportunitätskosten muss man auch berücksichtigen
    • Wenn man Investment aufnimmt, um die monatlich nötigen Kosten zu decken, muss es aus Investorensicht Potenzial für hyperrasantes Wachstum geben, damit die Portfoliologik aufgeht
      Wenn man von Anfang an auf ein kleines, nachhaltiges Geschäft zielt und erfolgreich ist, kann man Investment vermeiden, aber wenn man erst in der mittleren bis späten Phase des Unternehmens in eine komplett neue Richtung pivotiert, hat man wahrscheinlich den Großteil der Rücklagen bereits verbrannt
    • Dann wäre es sinnvoller, bei einem großen Unternehmen anzufangen und eine ähnliche Vergütung ohne Risiko zu bekommen
    • Ich habe mich das auch gefragt. Ich bin einer von drei Mitgründern eines bootstrapped Beratungsunternehmens in einer Region mit niedrigen Lebenshaltungskosten, und wir zahlen den Gründern seit einigen Jahren jeweils 50.000 Dollar Jahresgehalt; wir hatten weder außergewöhnliches Glück noch besonders geniale geschäftliche Entscheidungen, und trotzdem läuft es ziemlich gut
      Dieses Jahr liegen wir bei 400.000 Dollar Umsatz, 150.000 Dollar Gewinn und 40 % Wachstum, und der Geschäftsausblick ist deutlich besser als zu Jahresbeginn
      Auch nächstes Jahr erwarten wir starkes Wachstum, und der Markt ist weit von einer Sättigung entfernt, sodass es noch mehrere Jahre Wachstumsspielraum gibt
      Nimmt man Gehalt plus ein Drittel des Gewinns, sind das dieses Jahr 100.000 Dollar, und bei 40 % Wachstum verdoppelt sich das Unternehmen etwa alle zwei Jahre. Wenn es gut läuft, ist allein Gehalt plus Gewinn schon ziemlich attraktiv, und dazu kommt noch die Möglichkeit eines Exits, bei dem die Gründer mehrere Millionen Dollar verdienen könnten
    • Da schwingt für mich ein Unterton von „Siehst du, ich habe doch gesagt, dass es schwer ist!“ mit
      Zu versuchen, ein Unternehmen wie Google aufzubauen, und zu versuchen, ein Unternehmen wie Basecamp aufzubauen, ist beides völlig okay; es sind einfach unterschiedliche Arten von Unternehmen
      Eher unterschätzt man leicht das Risiko, ein „risikoarmes Geschäft“ aufzubauen, und jedes Unternehmen ist schwer. Applaus für Konfig

  • Als Kunde von Konfig finde ich das wirklich schade. Wir waren wahrscheinlich einer der ersten Kunden, und ich glaube, wir wurden sogar in frühen Commits erwähnt
    Dylan und Anh-Tuan haben für uns mehrere reale Probleme wirklich hervorragend gelöst. Sie boten generierte SDKs und ansprechend gehostete Dokumentation/Tutorials an einem Ort, und wir konnten unsere API aufrufen lassen, damit Nutzer sofort mit echten Daten experimentieren konnten
    Vor Konfig haben wir SDKs als Wrapper um unsere API manuell und uneinheitlich geschrieben, und die Dokumentation wurde zwar mit ReadMe gehostet, funktionierte aber wegen der Anforderungen an die Signierung von Requests für unsere API nicht gut interaktiv
    Dank der Open-Source-Veröffentlichung von Konfig hosten wir die Dokumentation jetzt selbst: https://docs.snaptrade.com/
    Ich habe großen Respekt vor diesem Team und wünschte, sie hätten irgendwie einen Weg gefunden weiterzumachen
    Wenn ihr ein Produkt wie Konfig betreibt, das die Kunden lieben, dessen Umsatz aber nicht auf das nötige Niveau wächst, sollte man auch höhere Preise in Betracht ziehen. Wir hätten locker das Zwei- bis Dreifache von dem bezahlt, was Konfig berechnet hat, und mit unserem Wachstum auch noch mehr, aber sie haben nie darum gebeten und auch kein nutzungsbasiertes Preismodell eingeführt, etwa eine monatliche Gebühr pro SDK oder pro Demo

    • Über euer Produkt bin ich auf Konfig aufmerksam geworden. Die Dokumentation war so gut, dass ich unbedingt nachsehen musste, was im Hintergrund verwendet wird, und sie ist wirklich viel besser als Swagger oder Redoc
    • Ich frage mich, ob ihr https://github.com/OpenAPITools/openapi-generator nie direkt ausprobiert habt
    • Wenn du eine schlanke Alternative für API-Dokumentation suchst, empfehle ich Scalar. Es ist einfach und leicht zu benutzen und viel besser als Swagger-Dokumentation

  • Die amerikanische Startup-Kultur ist wirklich seltsam. Nicht alles muss auf Hyperwachstum ausgelegt sein, und nicht alles muss riesig werden
    Unternehmen sollten sich stärker auf Nachhaltigkeit konzentrieren, statt nach zwei oder drei Pivot-Wechseln in 2–3 Jahren zu schließen

    • Einerseits stimmt das, andererseits hat genau dieser hartnäckige Fokus auf „entweder massiv skalieren oder scheitern“ das amerikanische Startup-Ökosystem womöglich erst an seine heutige Position gebracht und ist vielleicht der Grund, warum es dem Rest der Welt so weit voraus ist
      Wenn man vielen europäischen Startup-Gründern sagt: „In fünf Jahren stagniert ihr bei 15–20 Mitarbeitenden, habt einen stabilen Cashflow und zahlt euch selbst 200.000–250.000 Dollar im Jahr“, würden sie das als großen Erfolg sehen. In den USA würde das, besonders mit Venture Capital, als Misserfolg gelten können
      Ich habe einmal einen Venture-Capital-Investor aus dem Silicon Valley ganz offen sagen hören, dass jemand das falsche Mindset habe und für ihn kein Partner sei, wenn er den Verkauf seiner Firma für 50 Millionen Dollar als Erfolg betrachte
      Wenn man keine großen Herausforderungen annimmt und keine großen Risiken eingeht, sondern sich mit kleinem Erfolg und stabilem Wachstum zufriedengibt, wird man nie die großen Gewinne einfahren. Für den Einzelnen mag das gesünder sein, für die gesamte Wirtschaft kann es aber schlecht sein
    • Kleine profitable Unternehmen, also womöglich langweilig wirkende Firmen mit kleinen Teams und langfristigen Zielen, landen wahrscheinlich gerade deshalb selten auf der HN-Startseite, weil sie sich keine unrealistisch großen Ziele setzen
      Interessant ist, dass diese Kultur die Mentalität „move fast and break things“ übernimmt, aber scheinbar fast nur in der Tech-Branche. Auch dass jemand nach mehreren gescheiterten Unternehmen als „Serial Entrepreneur“ bezeichnet wird, passt dazu; den Verkauf eines nicht nachhaltigen Unternehmens als Erfolg zu sehen, fällt mir schwer
      Es ist schon lustig, sich vorzustellen, wie es klingen würde, wenn jemand, der in mehreren Sportarten gescheitert ist, sich selbst „Seriensportler“ nennen würde
    • Das Problem ist, dass man in dem Moment, in dem man Venture Capital annimmt, in Richtung Hyperwachstum gedrängt wird
      Wenn man kein Venture Capital aufnimmt, ist der Weg zur Tragfähigkeit viel schwieriger und dauert viel länger, es sei denn, man kann sich etwa über Consulting selbst finanzieren. Das Vorbild hier ist 37 Signals, aber die sind mit Rails groß geworden und damit eine ziemliche Ausnahme
      Und selbst wenn man diesen Punkt erreicht, kann ein VC-finanzierter Konkurrent mit besseren Kontakten und mehr Kapital hereindrücken und einen niederwalzen
    • Ich bin in Europa und arbeite in einer Firma mit genau denselben Schwierigkeiten
      B2B-Vertriebszyklen bei Großunternehmen sind absurd lang, und die Preispunkte, zu denen man an KMU verkaufen kann, reichen nicht aus
      Selbst wenn wir Wert schaffen und unseren Kunden Zeit sparen, ist es immer schwer, diesen Wert zu erklären
      Die Wiese auf der anderen Seite wirkt immer grüner, aber wenn man ein B2B-Geschäft betreibt, jahrelang denselben Kampf wiederholt, nur um die Lichter anzulassen, jeden Monat ähnliche Gespräche mit anderen Kunden führt und zehnmal im Jahr dieselbe Erklärung liefern muss, warum das Ganze wertvoll ist, dann ist auch verständlich, dass viele darin nicht feststecken wollen. Burnout kann schnell kommen
      Deshalb kann ich auch verstehen, warum Leute nach Geschäftsideen suchen, bei denen der Wert sofort klar ist und die Menschen sagen: „Nehmt einfach mein Geld“
    • Dass westliche Unternehmen eher vertikal skalieren als horizontal, hat mehrere Gründe
      Der erste ist die Kapitalrendite. Wenn man fremdes Geld einwirbt, erwarten diese Leute selbstverständlich einen Ertrag, und kluge Investoren streuen ihr Portfolio, weil sie wissen, dass viele Investments scheitern werden. Deshalb setzen sie ihre Beteiligungen unter Druck, so groß wie möglich zu werden, damit einige wenige extreme Gewinner die Verluste ausgleichen
      Diese vertikale Skalierung sieht man nicht nur bei Startups, sondern auch bei Großunternehmen. Dabei spielen Formalismus, Überregulierung und Bürokratie aus meiner Sicht eine große Rolle. Wenn man sich durch unzählige Prozesse arbeiten muss — Genehmigungen, Steuern, Einrichtung von Lohn- und Gehaltskonten und so weiter — und für einen Börsengang noch mehr Verfahren durchlaufen muss, dann kann es viel günstiger und weniger riskant sein, den Tätigkeitsbereich eines bereits etablierten Unternehmens auszuweiten, statt eine neue Firma auszugründen

  • Wir waren wohl Konkurrenten. Ich bin der Gründer von ReadMe.com, und wir bieten API-Dokumentation, SDKs und Ähnliches an
    Warum genau wir erfolgreich waren, weiß ich nicht so recht, aber ich hatte ebenfalls zahllose Fehlstarts und habe die Kernidee Schritt für Schritt weiterentwickelt, bis wir an einen Punkt kamen, an dem die Leute sichtbar begeistert waren
    Weil ich wusste, dass dieser Markt schwierig ist, habe ich viel Zeit und Mühe auch in Dinge investiert, die nichts mit Engineering zu tun haben, und Hacker News war uns immer wohlgesonnen, besonders wenn wir uns ehrlicher und offener gezeigt haben
    Ich werde versuchen, mich privat zu melden, weil ich gern mehr hören würde
    Insgesamt Glückwunsch zu all der investierten Arbeit. Ein Unternehmen zu gründen und an sich selbst zu glauben ist unglaublich schwer, und darauf kannst du stolz sein

    • Es könnte sein, dass ReadMe gegenüber Konfig vor allem deshalb erfolgreicher war, weil ihr acht Jahre früher angefangen habt. Konfig war eine gute Idee und gut umgesetzt, aber vielleicht hat einfach das Timing nicht gepasst
    • Wenn ich schon mal hier bin: Der CSS-Übergangseffekt auf dem ReadMe-Login-Screen ist für mich eines der stärksten Branding-Elemente, an die ich mich erinnern kann. Wer auch immer sich das ausgedacht hat: wirklich großartig

  • Ich glaube, so etwas werden wir in naher Zukunft noch oft sehen. Wenn die AI-Blase platzt, wird sich Ähnliches wohl wiederholen

    • Wenn es stattdessen so formuliert worden wäre, hätte ich den Aufwand eher respektiert
      „Wir haben versucht, generative AI in einem vertikalen B2B-SaaS-Produkt einzusetzen, weil wir dachten, damit ein Problem lösen zu können, das vorher nicht lösbar war. Wir haben mehrere Ideen entwickelt und vorgestellt, aber die Reaktionen der Nutzer waren nicht positiv genug, um uns die Sicherheit zu geben, dass wir auf dem richtigen Weg zu einem großen Geschäft waren.“
      In der ursprünglichen Formulierung entsteht eher der erste Eindruck: „Die Person, die das geschrieben hat, steckt so tief in einer vorübergehenden, engen Trendkultur, dass es sofort abstößt, und selbst direkt nach einem vollständigen Scheitern hat sie sich psychologisch noch nicht davon gelöst“
    • Den Code als Open Source zu veröffentlichen und dann aufzugeben, ist der ultimative AI-Pivot. Neue Modelle werden aus dem lernen, was du gemacht hast, und es irgendwann besser können

  • Es ist nicht das erste Mal, dass ich höre, wie ein Produkt ohne klaren Fit bei der Suche nach einer Pivot-Richtung auf AI als Antwort gesetzt hat und gescheitert ist
    Ich habe das schon früher gesagt, aber es lohnt sich, es zu wiederholen. Wenn wir verstehen, was AI gut kann und was nicht, werden wir anfangen, AI nicht als Ziel, sondern als Werkzeug zu behandeln, und dann werden auch Produktideen wieder stabiler werden

    • Wir wissen das bereits. AI ist gut darin, plausibel klingende Inhalte zu erfinden, aber schwach darin, Ergebnisse zu liefern, die Tatsachen oder Überprüfung standhalten
    • Das Produkt selbst war in Ordnung. Ich war bei einem Startup, das für genau dieses Produkt — SDKs aus OpenAPI-Spezifikationen zu erzeugen — gern bezahlt hat und viel Wert daraus gezogen hat
      Deshalb glaube ich nicht, dass das Problem hier der Product-Market-Fit war
    • Heißt das, AI kann etwas automatisieren, aber keine schlechte Produktidee retten? So nach dem Motto: Etwas effizienter zu machen, das niemand haben will, ist noch kein Geschäft
    • Das Konzept von APIs sollte verschwinden, und stattdessen sollten AI-Systeme einfach in natürlicher Sprache miteinander sprechen

  • Ich bin mir nicht ganz sicher, wie ich das bewerten soll. Einerseits gebührt Anerkennung für die Selbstreflexion, dafür, dass man sich unbequemen Wahrheiten gestellt hat, und dafür, dass ein ziemlich breites Toolset gebaut wurde
    Wenn man jedoch ins Innere schaut, ist es ein Tool, das andere Tools umhüllt. Das API-Klassifizierungstool scheint einen erheblichen Teil der schweren Arbeit an OpenAI zu delegieren
    „Sie sind ein Klassifizierer von Weltklasse. Ordnen Sie diese APIs einer dieser Gruppen zu.“
    Der Rest der Dateien ist Verkabelungscode, bei dem die Grenzen zwischen Model, View und Controller etwas verschwimmen. Es gab auch Tests, und ich dachte, das wäre bei Tool-Wrapping wichtig, wo es viele Änderungen außerhalb der eigenen Kontrolle gibt, aber in Wirklichkeit war es eher auf dem Niveau der funktionalen contextLoads()-Tests, die IntelliJ standardmäßig mitgibt: also abhängigkeitsbezogen und nur darauf prüfend, dass die Kompilierung nicht fehlschlägt
    Es gibt eine Vision und sie passt auch zum Pareto-Prinzip, aber während man die Hypothese prüfte, dass der Markt kein Interesse daran hat, den eigenen Kram zu warten, wirkt es so, als hätte man intern nicht einmal das eigene Wartungsproblem lösen können
    Hätte man den Grund dafür zuerst für sich selbst lösen können, hätte man ihn vielleicht auch für andere lösen können; aber dafür hätte es ein tatsächlich genutztes Produkt gebraucht, um den Schmerz zu spüren und sich in Endnutzer hineinzuversetzen — ein Dilemma, wie es scheint

  • Ein gescheitertes Startup ist nichts, wofür man sich schämen müsste. Die meisten von uns haben nicht einmal den Mut, es zu versuchen
    Allzu großes Interesse am Code ist kaum zu erwarten. Der Wert von Firmen-Code ohne das Geschäft und die Menschen dahinter ist eher negativ, sofern darin keine besondere technische Geheimwaffe steckt
    Selbst wenn es technisch beeindruckende Teile gibt, wollen die Leute wahrscheinlich nur verstehen, wie genau dieser eine Teil funktioniert, statt den Code selbst zu verwenden

    • Ich bin der Gründer von Konfig. Stimme zu 100 % zu. Ich würde niemandem empfehlen, Konfig selbst zu entschlüsseln und auszurollen
      Ein Kunde hat es allerdings geschafft, unsere Dokumentationsplattform selbst zu deployen, während er nach einer Möglichkeit suchte, die Folgen der Einstellung von Konfig zu bewältigen
    • Was ich mir nach mehreren Startups, die mit der Zeit immer weniger gescheitert sind, mühsam erarbeitet habe, ist Folgendes
      Ohne einen Geschäftsplan, der schnell Umsatz bringt, oder ohne massive Finanzierung sollte man kein Tech-Startup gründen. In der Regel ist es schon schwer, Investitionen zu bekommen, wenn man nicht wenigstens ein grobes Gefühl dafür hat, wohin das Geschäft gehen soll, und Techniker verstehen die geschäftliche Seite meist nicht ausreichend
      Die meisten Unternehmen sind keine Startups, sondern einfach Unternehmen. Unternehmen mit Umsatz, die ihre Rechnungen bezahlen. Ein Startup ist ein Unternehmen, das ohne Umsatz von geliehener Zeit und geliehenem Geld lebt, und besonders wenn dieses Geld das eigene ist, braucht man einen Plan
      Die meisten venturefinanzierten Unternehmen scheitern. Die Aufgabe von Venture Capital ist es, Firmen, die scheitern werden, schnell scheitern zu lassen, und das eigene Geschäft mit den wenigen Firmen zu tragen, die nicht scheitern und explosionsartig erfolgreich werden. „Beschleunigung“ oder „Investment einsammeln“ bedeutet nicht, dass man auf einem Erfolgspfad ist, sondern dass man auf einer Position sitzt, auf der man die Wahrscheinlichkeiten schlagen muss und nicht mehr viel Zeit bleibt
      Ein erfolgreiches Unternehmen mit Umsatz braucht kein Venture Capital. Dann sollte man sich fragen, warum man überhaupt mit ihnen spricht. Wenn es schwer ist, Umsatz zu machen, wird Venture Capital das nicht reparieren
      Viele Venture-Capital-Geber sind träge und zeigen erst Interesse, wenn der Erfolg bereits da ist. So entsteht eine merkwürdige Dynamik, in der früh finanzierte Firmen scheitern und nicht finanzierte Firmen erfolgreich werden
      Mein aktuelles Unternehmen ist seit vier Jahren vollständig gebootstrapped. Wir kämpfen um Umsatz, füllen Arbeit in die verfügbaren Stunden, und ich lebe hauptsächlich von nebenbei laufender Beratung. Das Unternehmen hatte drei Jahre in Folge sein erfolgreichstes Jahr, und wir nähern uns dem Punkt, an dem ich die Beratung aufgeben und mich auf das Geschäft konzentrieren kann, aber es war ein langer Weg
      Was Open Source betrifft, veröffentliche ich alles, was kein geschäftsspezifischer Code oder zentrales geistiges Eigentum ist. Ein großer Grund ist auch, dass ich beim nächsten Unternehmen nicht denselben Kleinkram noch einmal bauen will. Ich habe erlebt, dass solche Dinge einen ausbremsen
      Viele Menschen in Startups sind auf geistiges Eigentum fixiert, aber realistisch betrachtet ist die meiste Software nicht so viel wert. Trotzdem kostet es Zeit, Geld und Energie, sie zu bauen
      Deshalb veröffentliche ich viele Tools und Frameworks, bei denen ich selbst der Hauptnutzer wäre. Um sie auch im nächsten Projekt weiterzuverwenden

  • Der Code-Dump an sich könnte interessant sein, aber es scheint keine Lizenz dabeizusein. Mit einer ordentlichen Open-Source-Lizenz wäre das viel nützlicher

    • Etwa eine Stunde nach dem Kommentar wurde eine MIT LICENSE-Datei hinzugefügt

  • Der Markt für Entwicklertools ist wirklich hart
    Fast jede Architekturentscheidung wird zu „Welches Open-Source-Tool können wir verwenden, um dieses Problem zu lösen?“
    Niemand will dafür bezahlen, und das ist okay

    • Das stimmt zwar, aber die meisten Entwickler nehmen Probleme außerhalb ihrer eigenen Probleme kaum wahr, und diese Probleme sind oft Probleme von Entwicklertools
      Deshalb gibt es so viele Firmen, die Startups für Entwicklertools bauen, obwohl in anderen Bereichen ein enormer Bedarf besteht
      Wenn es für erfahrene Entwickler, die etwas starten wollen, eine Möglichkeit gäbe, Menschen mit Problemen, Domänenexpertise und Gründungswillen nicht nur über Zufall und Networking zu finden, könnte viel Wert freigesetzt werden
    • Entwicklern Tools zu verkaufen ist schwer. Man muss mit zahllosen Open-Source-Tools konkurrieren, die sich ständig anpassen und verändern, und gute Ideen werden schnell aufgenommen und kopiert
      Deshalb haben die meisten kommerziellen Tools in Bezug auf ihren Nutzen nur eine begrenzte Lebensdauer und bleiben meist eher nice-to-have
      Außerdem sind viele Entwickler angestellt und haben kein persönliches Budget für Tools. Der Markt verengt sich faktisch auf freiberufliche Entwickler oder Manager, die Entwickler beschäftigen
      Teamleiter prüfen solche Ausgaben genau und haben meist auch kein großes Budget. In den meisten Unternehmen gibt es schlicht kein persönliches Tool-Budget für Entwickler
      Auch Freelancer nutzen meist die Tools, die die Unternehmen verwenden, die sie bezahlen, und das sind in der Regel kostenlose Tools. Bei kostenpflichtigen Tools muss man sich auch noch um Lizenzen für Auftragnehmer kümmern, was den Einsatz von Freelancern zusätzlich kompliziert macht. Deshalb neigt man dazu, solche Tools zu vermeiden, um es einfach zu halten
    • Darüber hinaus sind Entwicklertools auf eine irreführende Weise schwierig. Es kann leicht so aussehen, als sei der Bau von Entwicklertools die Erfolgsformel für ein Unternehmen oder Startup. Schließlich ist man selbst Entwickler und hat wahrscheinlich ein Problem gefunden, das man in der Vergangenheit selbst erlebt hat
      Man weiß auch, wo sich Entwickler aufhalten und was gut ankommt, also wirkt alles gut
      Aber wie gesagt: Viele Entwickler wollen nicht bezahlen und suchen lieber nach einer Open-Source-Lösung, die die nötige Arbeit erledigt, auch wenn sie etwas weniger bequem ist. Und weil die Gegenseite aus Menschen besteht, deren Beruf und Leben darin besteht, Software zu bauen, kann die Antwort auch einfach sein: „Dann baue ich es eben selbst.“
    • Nicht ganz falsch. Ich möchte nur keine Zeit damit verschwenden, 50 Rechnungen über 10 Dollar zu bearbeiten
      Gibt es kein Unternehmen, das mehrere Services zu einer einzigen Rechnung bündelt? Oder muss man immer noch AWS, Azure und GCloud verwenden?