4 Produkte alleine launchen
Ich habe in einem Jahr vier Produkte veröffentlicht.
Dazu gehören spectr-ai, Scry, Argus und Lomi. Sie decken die Bereiche Security, Web3, Browser-Extensions und B2B-SaaS ab.
Diese alleine zu entwickeln, hat mich Lektionen gelehrt, die kein einzelnes Projekt hätte vermitteln können.
Hier ist das, was ich gelernt habe.
- Plane Zeit für die langweiligen Teile ein.
Ich habe meine Energie in schwierige technische Probleme gesteckt. Ich habe mich auf KI-Analysen und Bytecode-Rekonstruktion konzentriert. Diese Teile waren schwer, aber vorhersehbar.
Die eigentlichen Bedrohungen waren die unglamourösen Aufgaben. Reviews im Chrome Web Store, Proxy-Auflösung und das Deployment-Setup hätten meine Projekte fast zum Scheitern gebracht.
Die eigentliche Arbeit liegt oft in der Integration an den Rändern. Ich habe dafür jedes Mal zu wenig Zeit eingeplant.
- KI macht den Anfang günstig, nicht das Ende.
Man sagt, KI erlaube es einer einzelnen Person, ein Unternehmen aufzubauen. Die Wahrheit ist spezifischer.
KI erledigt die ersten 80 % eines Features. Sie erstellt den Boilerplate-Code und entwirft die Tests. Das macht Solo-Arbeit möglich.
Die letzten 20 % erledigt die KI nicht. Dazu gehören Edge Cases, Security-Reviews und das Debugging instabiler Verbindungen. Dieser Teil ist immer noch langsam. Er erfordert nach wie vor deine volle Aufmerksamkeit.
- Umbenennen ist Fortschritt.
Ich habe mehrere Projekte umbenannt, während sie gewachsen sind. Früher dachte ich, Umbenennen bedeute verschwendete Mühe.
Ich habe mich geirrt. Eine Umbenennung bedeutet, dass du das Produkt endlich verstehst. Der Code bleibt gleich, aber deine Klarheit verbessert sich.
- Logik geht vor Feinschliff.
Ein hübsches UI ist eine Falle. Wenn sich die Funktionalität ändert, musst du das Design überarbeiten. Das verschwendet Zeit.
Meine Regel ist einfach: Schließe die Logik und die Tests ab, bevor du mit dem Styling beginnst. Ein Feature funktioniert erst dann, wenn ein Test es beweist. Mach es nicht hübsch, bevor es funktioniert.
- Schreibe über die Misserfolge.
Building in public bedeutet auch, die schlechten Seiten zu teilen.
Ich habe über Hacks, gescheiterte Ansätze und Bugs geschrieben. Das hat mich mehr gelehrt, als wenn ich im Stillen gearbeitet hätte. Es hat zudem ein Publikum aufgebaut, das sich für deinen Prozess interessiert.
Wenn du alleine entwickelst, folge diesen Regeln:
• Verbringe mehr Zeit mit der Integration als mit dem Kern-Feature. • Nutze KI für die Fleißarbeit, aber erledige die schwierigen 20 % selbst. • Priorisiere Tests vor dem UI. • Teile deine Fehler während des Prozesses.
Veröffentlichen ist ein Verb. Es ist kein abgeschlossener Zustand. Es viermal getan zu haben, hat mich mehr gelehrt, als die Perfektionierung eines einzelnen Produkts jemals könnte.
Optionale Lern-Community: https://t.me/GyaanSetuAi