Die traurigste „Just Ship It“-Geschichte (2020)

• Ein 2018 gestartetes Nebenprojekt hatte nach wenigen Tagen ein MVP fertig, wurde aber durch immer weiteres Aufschieben der Veröffentlichung zu einem zwei Jahre lang unveröffentlichten Projekt
• Im Zentrum der Verzögerung stand die wiederholte Entscheidung „nur noch eine Sache“, und der Produktumfang wuchs, während sogar React Native und Expo gelernt wurden
• Eine konkurrierende App, die dasselbe Problem löste, war langsam und hatte Bugs, war aber bereits veröffentlicht, hatte Nutzer und eine Community gewonnen und wurde jede Woche verbessert
• Als nach der 30-tägigen Testphase für die Konkurrenz-App bezahlt wurde, wurde die eigene App, die nur noch auf der Festplatte lag, praktisch zu einem toten Produkt
• Im Update von 2024 heißt es, dass die Produktivitäts-App Benji 2022 schließlich veröffentlicht wurde; das Fazit geht, so abgedroschen es klingt, eher in Richtung: erst einmal rausbringen

---

Warum ein in wenigen Tagen gebautes MVP zwei Jahre lang nicht veröffentlicht wurde

• Die App-Entwicklung begann am 1. Januar 2018, und das MVP war nach wenigen Tagen bereit
• Auch eine Alpha-Version 0.0.1 hätte veröffentlicht werden können, doch jedes Mal wurde der Launch mit „nur noch ein Feature“ oder „nur noch ein Screen“ verschoben
• Aus der Einschätzung heraus, dass „die Leute es nicht nutzen werden, wenn es keine richtige native Mobile-App gibt“, wurde React Native gelernt und beschlossen, noch ein paar Monate mehr zu investieren
• In den folgenden zwei Jahren wiederholten sich Web-Plattform, React Native, Expo, GraphQL, Überlegungen zum Tech-Stack, der Wechsel zu anderen Projekten, der Launch anderer Apps wie Sizzy sowie Verlust und Wiederkehr der Motivation
• Am Ende wurde die Entwicklung gestoppt und auch die Idee aufgegeben, diese App zu veröffentlichen

Der Moment, in dem eine App entdeckt wurde, die dasselbe Problem löste

• Mit der Zeit wurde die eigene App weiter genutzt, wodurch klar wurde, dass viele Funktionen benötigt wurden; damit entstand die Situation, entweder wieder daran zu entwickeln oder nach einer Alternative zu suchen
• Beim Anblick der Landingpage einer Alternativ-App kam stark das Gefühl auf, dass jemand das Problem, das man selbst lösen wollte, bereits gelöst hatte
• Da zuvor ein Video der eigenen App an einige Leute geschickt worden war, wirkten Funktionen und Problemverständnis so ähnlich, dass sogar der Verdacht aufkam, dieses Video könnte weitergegeben worden sein
• Die Existenz der Konkurrenz-App wurde jedoch nicht als deren Fehler verstanden, sondern als Folge davon, dass man selbst zu langsam war und nicht rechtzeitig veröffentlicht hatte

Die Konkurrenz-App stellte den Launch vor Perfektion

• Beim Erstellen eines Accounts und beim Ansehen von Videos im Help Center wurde in jedem Moment, in dem die Umsetzung clever wirkte, bewusst, dass es sich um einen Konkurrenten handelte
• Zwei Jahre lang hatte die Annahme gegolten, die eigene App sei unfertig, fehlerhaft und funktionsarm, sodass niemand sie nutzen würde; beim Ausprobieren der Konkurrenz-App zeigte sich, dass diese Einschätzung falsch war
• Auch die Konkurrenz-App war jahrelang entwickelt worden, war aber weiterhin langsam, hatte Bugs und war noch nicht stark poliert
• Die Mobile-App war so schlecht, dass die Synchronisierung 10 Sekunden dauerte, aber sie war bereits ein veröffentlichtes Produkt, und Nutzer konnten auf das nächste Update warten
• Trotz einer großen To-do-Liste wurde jede Woche weiter veröffentlicht, sodass App und Community gemeinsam wuchsen

Die Lehre nach der Zahlung

• Nach Ablauf der 30-tägigen Testphase wurden Kreditkartendaten eingegeben, und aus einem bloßen Abonnenten wurde ein Fan
• Die Zahlungsbenachrichtigung blieb als Erlebnis zurück, das immer wieder daran erinnerte, selbst nicht veröffentlicht zu haben
• In diesem Moment wurde akzeptiert, dass die eigene App offiziell tot war
• Die meisten Menschen in derselben Situation haben ihr Projekt vielleicht erst vor ein paar Wochen begonnen, daher sollten sie denselben Fehler vermeiden
• Wenn „nur noch eine Sache“ bedeutet, Authentifizierung, Zahlungen oder Boilerplate neu zu bauen, ist genau das die Falle; um diese Falle später zu verkleinern, wurde Zero To Shipped erstellt

Update 2024: Benji wurde schließlich veröffentlicht

• Laut dem Update von 2024 wurde Benji 2022 schließlich veröffentlicht
• Der Grund für den Launch war, dass keine Konkurrenz-App der eigenen Vision nahe genug kam
• Die gewünschte App war eine Kombination aus Todos, Habits, Planner, Goals, Pomodoros, Meal tracking, Fasting, Hydration, Packing, Trips und Ähnlichem
• Benji enthält außerdem eine öffentliche Timeline, auf der Menschen ihr Leben verbessern und Erfolge sowie Errungenschaften teilen
• Auch wenn es abgedroschen klingt: kurz durchatmen und trotzdem Just Ship It

[GN⁺]

Hacker-News-Kommentare

• Bei solchen Geschichten im Stil von „es ging am Ende schief, weil wir damals nicht einfach veröffentlicht haben“ gibt es einen wichtigen Hinweis: Manchmal liegt der Wert der App in technischen Details, die man nicht überhasten kann, und dann ist „einfach veröffentlichen“ eben nicht die richtige Antwort
  Die Aufgabe von Softwareingenieuren/-architekten besteht auch darin, dem Druck des Managements, „es einfach rauszuschicken“, so gut wie möglich standzuhalten. Wenn es nicht ein Produkt ist, das man selbst besitzt und bei dem einem die Veröffentlichung direkt nützt, dann sollte man sich die Zeit nehmen, wenn das zu einem professionelleren Ergebnis führt. Man ist keine Maschine, die ein JIRA-Ticket bekommt und dann möglichst schnell schlampigen Code ausspuckt; wer so dauerhaft arbeitet, zehrt sich mental aus und landet am Ende im Burnout
  Wenn man keine Firmenanteile hat, ist es nicht die eigene Aufgabe, den Gewinn des Unternehmens zu maximieren, sondern gute Software zu bauen, die man ohne Scham in den Lebenslauf schreiben kann. Die Erleichterung, wieder irgendeine willkürliche Deadline eingehalten zu haben, ist nur eine kurzfristige negative Motivation und hält nicht lange; man muss dem Druck von oben widerstehen und es ordentlich machen. Selbst wenn man deshalb gefeuert wird, ist ein Jobwechsel heutzutage sowieso der Weg nach oben

  • „Wenn du keine Firmenanteile hast, musst du dich nicht um Profitabilität kümmern“ wirkt wie eine schlechte Haltung, die mangelnde Seniorität bei Softwareentwicklern zeigt. Sofern es keine Non-Profit-Organisation ist, sollten alle im Unternehmen zur Profitabilität beitragen
    Profitabilität bedeutet allerdings nicht „einfach veröffentlichen“. Wenn eine Firma diese beiden Dinge oft verwechselt, ist das eher ein Zeichen mangelnder Seniorität im Management
    Die Aufgabe von Entwicklern ist nicht so sehr, gute Software zu bauen, sondern eher, gute Produkte zu bauen. Gute Produkte brauchen meistens gute Software, aber nicht immer, und hinter großartigen Produkten steckt oft miserable Software. Die Spannung zwischen Produkt, Vertrieb und Entwicklung sollte zu Kompromissen führen, die kurz-, mittel- und langfristigen Wert maximieren, und Entwickler müssen verstehen, was man grob behandeln darf, welche Prioritäten das Unternehmen hat und wann man eben keine Kompromisse eingehen und gute Software bauen sollte
    Entwickler, die bei Softwarequalität nie Kompromisse eingehen können, verlieren gerade dann an Schlagkraft, wenn man tatsächlich keine Kompromisse eingehen darf
  • Man muss zuerst darauf schauen, warum man überhaupt entwickelt. Vielleicht als Hobby, aus Freude oder wegen der Schönheit des Codes, aber meistens geht es darum, Software Aufgaben erledigen zu lassen, die jemand braucht
    Deshalb ist Priorität Nummer eins, Wert für die Nutzer zu schaffen und dabei so effizient wie möglich zu entwickeln. Was bringt Software, die niemand benutzt
    Die Aufgabe von Entwicklern ist nicht, gute Software zu bauen, sondern Wert für die Nutzer zu liefern. In meiner Laufbahn habe ich eher gesehen, dass Entwickler sich in Overengineering verlieren, den Code mit Funktionen aufblähen, die niemand braucht, und ihn für zukünftige Entwicklungen aufblähen, die nie kommen. Die schwierige Aufgabe ist deshalb eher, minimal zu bleiben, und genau darum scheint es im Original auch zu gehen
  • Der ganze Kommentar liest sich, als würde hier jemand Beziehungen zu Kollegen rein antagonistisch sehen und fast kein Vertrauen haben. Klingt ziemlich anstrengend
  • Ich war einer der ersten Mitarbeiter in einem Startup, und wenn wir keine Kompromisse gemacht hätten, würde das Unternehmen heute wahrscheinlich nicht existieren. So ein Ansatz funktioniert eher in großen, etablierten Unternehmen, in denen der Einfluss des Teams auf das Ergebnis begrenzt ist
    In kleinen und mittleren Unternehmen braucht man definitiv Kompromisse, und zu professionellem Arbeiten gehört auch, Entscheidungen zu treffen, die zum besten geschäftlichen Ergebnis führen
    Viele Entwickler sind durch mehrere Ebenen von Managern, PMs und Designern so sehr „geschützt“, dass ihre Verbindung zur Geschäftsseite schwach ist. Wenn man ein Produkt schnell ausliefert, bekommt man auch schneller Feedback und die Chance zu bewerten, ob die Umsetzung zu den Annahmen passt. Es war weniger stressig, unter Druck eine „perfekte“ Lösung auszurollen und sie danach neu schreiben zu müssen
    In meinem aktuellen Job besteht meine Arbeit als Entwickler darin, Komplexität zu reduzieren und PMs sowie Designer dazu zu bringen, ihre ursprünglichen Pläne auf ein Minimum herunterzukürzen. Dann sind auch willkürliche Deadlines weniger stressig und die Folgen von Verzögerungen kleiner
  • Klingt wie Satire. Da kommen markige Sätze hintereinander wie: „Wenn es nicht dein eigener Job ist, mach die falsche Sache, und wenn es dein eigener Job ist, veröffentliche schnell“ oder „deine Aufgabe ist es, etwas zu tun, das sich gut im Lebenslauf anfühlt“
    Der wertvolle Teil ist höchstens, sich nicht zu sehr an einen bestimmten Arbeitsplatz zu klammern und Kündigungen nicht übermäßig zu fürchten, aber selbst die Begründung dafür halte ich für falsch. Dass man mit Leuten mit so einer feindseligen Haltung tatsächlich zusammenarbeiten könnte, ist schon erstaunlich
    Manche Menschen scheinen ein Leben in dem falschen Quadranten der Spieltheorie zu mögen

• Bei der Stelle „Ich fragte mich, wer diesen Leuten das Video meiner App gezeigt hatte. Sie lösten buchstäblich dasselbe Problem“ musste ich daran denken, dass ich einmal jemanden mit einer ganz ordentlichen App-Idee getroffen habe
  Er wollte, dass ich die App kostenlos programmiere und wir die Einnahmen teilen. Auf die Frage, was er selbst beitragen würde, sagte er, er würde das Unternehmen „führen“, und seine 50 % stünden ihm zu, „weil er die Idee hatte“. Also sagte ich ihm, ich würde ihm sechs Monate Vorsprung geben, und wenn er sie bis dahin nicht auf den Markt bringt, würde ich sie selbst bauen

  • Ich habe einmal an einem Indie-Game-Projekt mitgewirkt. Die Idee war ziemlich durchschnittlich und eher nah an einem schlechten Spiel, aber wir alle drei wollten Erfahrung in der Softwareentwicklung in diesem Bereich
    Zwei von uns setzten sich einfach hin und begannen, eine Form daraus zu machen, aber der Dritte lud kaputten Code in SVN hoch, schrieb ein Designdokument, in dem er sich die gesamte Idee zuschrieb, berief dann ein Meeting ein und erklärte, er sei der Game-Designer und würde uns verklagen, wenn wir anderswo ein Spiel daraus machten. Die zwei, die tatsächlich beitrugen, sahen sich an und stellten das Projekt ein. Er hatte alle Karten offengelegt, und wir wussten jetzt, dass er ein Niemand war
    Später habe ich auf Steam ein Spiel mit einer ähnlichen Idee gesehen. Wenn sie unabhängig darauf gekommen sind, schön für sie, und wenn sie es von diesem Loser geklaut haben, auch gut; und wenn sie es unter ihm bis zum Ende ausgehalten haben, dann haben sie das Geld verdient
  • Als jemand, der extrem stark zu Logik und Programmierung neigt, würde ich so jemanden im Gegenteil gern mal treffen. Ich selbst bin wohl nicht der Typ Mensch für Ideen
    Wenn die Idee wirklich gut und glaubwürdig gewesen wäre, dann wäre es ehrlich gesagt vielleicht sogar ein ziemlich gutes Angebot gewesen
  • Vertrieb, Marketing, Buchhaltung und alles andere zu erledigen, was man für den Betrieb eines Unternehmens braucht, ist 50 %, vielleicht sogar mehr, wert. Allerdings war die Person, die coden sollte, wahrscheinlich kompetent genug, aber dass er kompetent genug war, ein Unternehmen zu „führen“, wirkt eher unwahrscheinlich
  • Wenn man den mentalen Zustand des Gegenübers überhaupt nicht kennt, weiß ich nicht, ob es klug ist, so etwas zu sagen
    Wenn du glaubst, man könne jemandem sagen: „In sechs Monaten klaue ich deine tolle Idee“, dann sollte man hoffen, dass diese Person nicht der Typ ist, der Ärger macht oder im Extremfall sogar Schaden zufügt

• Es wäre schön, wenn jemand mein Problem für mich lösen würde. Ich beschäftige mich nur deshalb damit, weil es keine Lösung gibt, die man einfach kaufen könnte.
  Wenn jemand mit Blut, Schweiß und Tränen mein Problem löst und dazu noch On-Call und Wartung übernimmt, ist das doch großartig.
  Warum muss man dieses Problem unbedingt selbst lösen? Warum muss die eigene Lösung unbedingt ein Geschäft sein? Bei einem Geschäft geht es darum, für sich selbst und für Kunden Wert zu schaffen. Wenn man auf das Problem selbst fixiert ist, sollte man dankbar sein, wenn jemand anderes sich mit großem Aufwand darum kümmert. Wenn man auf den Kunden fixiert ist, hätte man längst irgendetwas für Kunden veröffentlichen sollen, um Feedback zu bekommen.

  • Manche Solo-Entwickler scheinen neue Ideen umsetzen, daraus ein einigermaßen erfolgreiches Geschäft aufbauen, den Markt dichtmachen und es dann für viel Geld an ein größeres Unternehmen verkaufen zu wollen.
    Nicht viele wollen ein Unternehmen langfristig betreiben, aber plötzlich viel Geld dafür zu bekommen, dass man ein interessantes Problem gelöst oder bearbeitet hat, lehnen die meisten vermutlich auch nicht ab.
  • Ich bin der Autor des Originals: Für mich war das wichtig, weil eine App, die ich eine Weile benutzt hatte, ins Stocken geraten war und keine Updates mehr bekam. Als ich mehr über Produktivität lernte, stieß ich an die Grenzen dieser App und wollte mehr Funktionen.
    Mir fielen ständig Ideen ein, die ich in meine App einbauen wollte, aber andere Entwickler hätten vermutlich kein Interesse gehabt, solche Ideen umzusetzen. Ich wollte Kontrolle, also habe ich schließlich Benji veröffentlicht: https://benji.so

• Ich bin der Autor des Originals. Ich sollte diesen Beitrag aktualisieren. Einige Jahre später haben mich die HN-Kommentare, die jedes Mal dazu auftauchten, tatsächlich motiviert.
  Die Leute sagten immer: „Warum veröffentlichst du die App nicht einfach?“, also habe ich sie schließlich veröffentlicht.
  Ich bin froh, dass ich es durchgezogen habe, und ich denke, sie ist deutlich besser als jedes Konkurrenzprodukt in dieser Kategorie.
  Man kann sie auf https://benji.so sehen. Die Landingpage ist allerdings noch in Arbeit.

  • Die Landingpage bringt meinen Browser ins Stocken. Es ist ein Startbildschirm mit ein paar Bildern, und ich verstehe nicht, wie das überhaupt möglich ist. Was genau macht ihr auf dieser Seite eigentlich?
  • Ich habe einen ähnlichen Zyklus mit einer App durchlebt, die ich nie veröffentlicht habe. Ich habe mit React angefangen, bin dann zu React Native und Flutter gewechselt und am Ende sogar von GraphQL zu SQLite.
    Meine App hatte ebenfalls ein ähnliches Ziel: Gewohnheitsmotivation, Messung der Zielerfüllung sowie die Planung und Umplanung von Aufgaben zusammenzubringen. Ich habe mehrere Jahre daran gearbeitet, und der Gedanke, daraus irgendwann ein gebootstrapptes Unternehmen zu machen, war stark mit meiner Identität verknüpft.
    Die Entscheidung, das Projekt loszulassen, kam in mehreren Phasen, aber ein großer Auslöser für den Abschluss war die Erkenntnis, dass ich langfristig nicht als App-Entwickler leben will. Loszulassen war schwer, aber ich bin heute zufrieden mit der Entscheidung. Wie im Original könnte es später vielleicht wieder auftauchen – in dem Sinn, dass „nichts jemals ganz verschwindet“ –, aber zu genau diesem Projekt werde ich wohl nicht zurückkehren.
    Eine meiner Kernideen, um die „hohe kognitive Last“ der meisten Produktivitäts-Apps zu überwinden, war ein Marketplace für Lebensmodule. Zum Beispiel könnte ein Fitness-Influencer Trainingsroutinen, Ernährungspläne und Journal-Vorlagen als Paket verkaufen, und Nutzer würden das dann in ihr Leben „installieren“.
    Große Sprachmodelle werden es viel eher möglich machen, Abwanderung zu erkennen, Ursachen zu vermuten oder auf „nicht ausgeführte Handlungen“ zu reagieren. Ich halte das für wichtig für Menschen, die keine Typ-A-Persönlichkeit haben und nicht jeden Tag konsequent Produktivitäts-Apps nutzen.
  • Ich habe es gerade ausprobiert, und der erkannte Zeitzonenname lautet „Africa/Ceuta (Romance Standard Time) (UTC+01:00) Brussels, Copenhagen, Madrid, Paris“.
    Der Unterschied zu GMT stimmt zwar, aber Brussels, Copenhagen, Madrid und Paris liegen nicht in Afrika, daher ist das ziemlich verwirrend. Ihr solltet euch die verwendeten Zeitzonendaten ansehen.
    Laut dem Kommentar unten war das dann doch kein Problem.
  • Die weißen Menülinks auf weißem Hintergrund sind nicht sichtbar. Ich lasse das mal da, falls es hilfreich ist: https://i.imgur.com/Yd1hniV.png
  • Sieht gut aus. Vielleicht probiere ich es mal aus. Ist der Name von diesem hier abgeleitet: https://en.wikipedia.org/wiki/Benji? Ich mochte das mit 6 bis 8 Jahren total gern.
    Und sorry, dass ich Frust und Misstrauen darüber geäußert habe, dass du den Namen des „Konkurrenten“ nicht genannt hast. Jetzt, wo du deine eigene App veröffentlicht hast, ist es wohl noch unwahrscheinlicher, dass du den Namen nennst, selbst wenn das Konkurrenzprodukt noch existiert.

• Wenn man selbst zum tatsächlichen Nutzer seines eigenen Systems wird, verändert sich die Perspektive komplett. Ich hatte auch etwas, das ich für mich selbst gebaut habe, und ich dachte, es sei nicht fertig und überhaupt nicht nutzbar.
  Nachdem ich das Projekt aufgegeben hatte, beschloss ich, es wie ein echter Nutzer zu verwenden, und stellte fest, dass Nutzer an zahllose kleine Probleme gewöhnt sind und automatisch Wege darum herum finden. Wer etwas baut, vergisst leicht, dass viele Unsauberkeiten kein Ausschlusskriterium sind und Nutzer viele Mängel ohne großen Aufwand umgehen. Ab diesem Punkt ist Perfektionismus fast schon Eitelkeit.
  Für eine Weile auszublenden, dass man der Ersteller ist, und es tatsächlich zu benutzen, während man sich zugleich verbietet, irgendetwas zu ändern, kann alles verändern.

  • Deshalb ist „veröffentlichen und schnell iterieren“ meiner Meinung nach oft der beste Weg. Jedes Softwareprojekt kann kritische Bugs haben. Wenn ein Buchhaltungspaket nicht richtig buchhalten kann, sollte man es natürlich nicht einfach veröffentlichen. Aber wenn ein Bericht aus irgendeinem Grund zweimal angezeigt wird, können Nutzer das bis zur nächsten Iteration verkraften. Die nächste Iteration darf dann nur nicht erst Monate oder Jahre später kommen.
    Realistisch gesehen findet man die meisten „Bugs“, auf die Nutzer stoßen, erst, wenn echte Nutzer Zugriff darauf haben. Wenn man nicht veröffentlicht, bekommt man auch nie die Chance, die Bugs zu beheben, die Nutzer tatsächlich betreffen.
  • Die App, die ich gerade benutzt habe, hatte einen eingebauten iOS-Webbrowser, der nicht richtig funktionierte.
    Ich habe dann einfach die Webseite direkt geöffnet, und Benutzername und Passwort wurden natürlich über iCloud synchronisiert. Es hat nur 5 Sekunden gedauert, den Nutzerfluss in Safari wieder aufzunehmen, und 30 Sekunden, um fertig zu werden.

• Als Beispiel für „einfach shippen“ ist das nicht gerade das beste. Kategorien wie Produktivitäts-Apps, To-do-Listen, Habit-Tracking, Ausgaben-Tracking, Journaling oder Trainingsplanung sind Bereiche, in denen viele Menschen unabhängig voneinander auf dieselbe Idee kommen
  Ich weiß noch, wie klug ich mich fühlte, als ich auf die Idee für eine App kam, mit der man Ausgaben erfassen kann. Und dann habe ich im Play Store nachgeschaut. KRAZAM hat sich darüber schon vor 5 Jahren in einem „The Hustle“-Video lustig gemacht

  • Das ist vermutlich die am meisten überentwickelte App-Kategorie in der Geschichte überentwickelter App-Kategorien
    Das heißt nicht, dass eine neue Variante keinen Erfolg haben kann. Die meisten erfolgreichen Dinge waren schließlich auch nicht völlig originell. Wenn du nur Angst hast, dass jemand anders zuerst seine Version veröffentlicht und gewinnt, musst du dich nur einmal umschauen
  • Der Teil mit „Ich habe im Play Store nachgeschaut“ scheint den Kern des Artikels zu verfehlen. Der Punkt ist, dass man auch dann veröffentlichen soll, wenn es Konkurrenten gibt. Konkurrenten sind eher ein gutes Signal zur Validierung der Idee als ein schlechtes

• Persönlich kann ich diesen Schreibstil von Leuten, die „krampfhaft witzig“ sein wollen, nicht ertragen

  • Stimme zu. Das Lesen ist ziemlich anstrengend. Ein oder zwei gut platzierte Spitzen sind okay, aber es sollte nicht zu viel werden
  • Damit bist du nicht allein, und es ist okay, wenn Menschen unterschiedliche Geschmäcker haben

• Ich habe beim Lesen aufgegeben. Viel zu kindisch und fremdschämig
  Am Ende wurde nur ein Proof of Concept gebaut und sich dann darauf ausgeruht. Schade, aber so ist das Leben. Sie haben die Arbeit gemacht und die Belohnung bekommen
  Die Lehre daraus ist, dass man Ideen nicht besitzen kann

• Dem stimme ich voll zu. Als wir Kviklet gestartet haben, waren wir zu dritt, und einer von uns war viel perfektionistischer als die anderen beiden. Ehrlich gesagt brauchte es schon viel Überzeugungsarbeit, um überhaupt die erste, offen gesagt ziemlich schlechte Version der Website online zu stellen, und das Repository öffentlich zu machen war noch schwerer
  Dieser „Mitgründer“ ist früh ausgestiegen, aber ich bin wirklich froh, dass wir früh veröffentlicht und versucht haben, es zu verkaufen
  Es hat nicht funktioniert und wir haben keinen Käufer gefunden, aber es wäre schrecklich, sich vorzustellen, dass wir immer noch im Dunkeln Produkte bauen würden, nur in der Hoffnung, ohne jede Ahnung, ob überhaupt jemand dafür zahlen würde
  Inzwischen haben wir es als Backup-Plan Open Source gemacht und ein paar ziemlich coole Nutzer gewonnen. Man könnte wohl sogar von einer kleinen Community sprechen: https://github.com/kviklet/kviklet
  Es ist nicht die Startup-Erfolgsgeschichte, die ich mir vor einem Jahr erhofft hatte, aber immer noch viel besser, als weiter nur Erwartungen hinterherzuhängen und den Realitätssinn zu verlieren. Open Source heißt ja nicht, dass man nicht doch etwas Geld mit Support oder einer Premium-Version verdienen könnte. Im Moment ist es einfach ein interessantes Side-Project

  • Die Beschreibung „ein Review-/Freigabe-Workflow wie Pull Requests für Datenbankabfragen“ ist nicht besonders gut. Abfragen sollten nicht nach etwas klingen, das genehmigt werden muss
    Man sollte Wörter wie mutation, edit, update oder modification verwenden. Auch wenn query technisch korrekt ist, klingt es semantisch falsch und verwirrend

• Wenn ich etwas für mich selbst baue, wäre ich nicht traurig, wenn jemand anders es schon vorher gebaut hätte. Das wäre nur ein Beweis dafür, dass die Idee gut war
  Natürlich sind viele der persönlichen Projekte in meinem Kopf und auf Papier, und sogar einige, die ich tatsächlich schon ein wenig angefangen habe, gar nicht dafür gedacht, als Verkaufsprodukt veröffentlicht zu werden. Es sind Dinge, die ich will oder die für Freunde, Familie oder andere nützlich sein könnten
  Wenn es auch nur Alpha-Qualität hat, würde ich es vielleicht veröffentlichen in der Hoffnung, dass jemand denkt: „Die Idee ist nützlich, aber die Umsetzung ist schwach, das muss ich besser machen“

  • Realistisch gesehen ist man in fast jeder Situation bereits von irgendetwas überholt worden. Selbst wenn man zum ersten Mal in der Geschichte etwas automatisiert, ist die bestehende manuelle Vorgehensweise der erste Konkurrent. Auch die App im Artikel konkurriert nicht nur mit anderen Apps, sondern auch mit allen möglichen Kombinationen aus Teillösungen, die die Zielgruppe bereits verwendet
    Außerdem wird es selbst als First Mover bald Konkurrenten geben, die den Vorsprung anfressen, und man muss sich weiter anstrengen, um vorne zu bleiben
    Wenn also sowieso immer schon jemand vor einem da ist und Konkurrenz jetzt oder später ohnehin sicher ist, dann sollte man sich nicht darum sorgen, dass jemand einem zuvorkommt, sondern auf den Wettbewerbsvorteil konzentrieren. Der Originalautor scheint am Ende ebenfalls zu dieser Erkenntnis gekommen zu sein, und ich hoffe, es läuft gut für ihn