Jira, Trello, Notion — und warum keins davon für Solo-Entwickler wirklich passt. Eine ehrliche Bestandsaufnahme.
Jedes Mal, wenn Entwickler ihre Toolchain optimieren — und dazu gehört heute zunehmend auch der Umgang mit KI-Assistenten —, landet irgendwann ein Aufgabentool auf dem Stack. Erst Sticky Notes. Dann Trello. Dann Notion. Dann Jira, weil “das alle nutzen”. Dann zurück zu einer einfachen Markdown-Datei — und das Gefühl, dass die Reise irgendwie rückwärts gegangen ist.
Das ist kein Zufall. Die meisten Task-Management-Tools sind für etwas anderes gebaut als das, was ein Solo-Entwickler täglich braucht.
Kanban-Boards lösen das falsche Problem
Kanban hat seinen Ursprung in der Produktionslinie und wurde für Team-Koordination adaptiert. Ein Board macht es für alle sichtbar, in welchem Status eine Aufgabe ist, wer sie bearbeitet und was als nächstes dran ist. Das ist wertvoll — in einem Team mit fünf Entwicklern, einem Projektmanager und asynchroner Kommunikation über Zeitzonen hinweg.
Für einen Solo-Entwickler löst das kein Problem. Es gibt keine Übergabe. Niemand wartet auf den Statuswechsel. Der Wert von Sichtbarkeit ist null, wenn die einzige Person, die schaut, dieselbe ist, die die Karte verschiebt.
Was bleibt: eine Karte, die von “In Progress” nach “Done” geschoben wird. Als Ritual. Als Simulakrum von Produktivität.
Was Entwickler tatsächlich brauchen
Drei Dinge helfen bei Solo-Arbeit, die Enterprise-Tools nicht gut abbilden:
Kontext-Zuordnung. Zu welchem Projekt gehört diese Aufgabe? Nicht als Filter auf einem Board, sondern als struktureller Anker. Die Frage “was mache ich gerade an welchem Projekt?” ist bei fünf parallelen Projekten keine triviale.
Fokus-Ansicht. Nicht alle offenen Aufgaben auf einmal, sondern: was ist jetzt dran? Eine Ansicht, die nicht mit Backlog-Items aus drei Projekten konkurriert.
Persistenz über Context Switches. Wenn ein Telefonat kommt, ein Bug-Fix dazwischenrutscht oder der Arbeitstag einfach abbricht — was war ich dabei, zu tun? Der Zustand muss nicht rekonstruiert werden, er muss da sein.
Das klingt nach wenig. Ist es auch. Aber genau dieser Anspruch — nicht mehr, nicht weniger — ist schwer zu finden.
Ein normaler Arbeitstag zeigt das Problem:
| Situation | Was ein Board zeigt | Was der Entwickler braucht |
|---|---|---|
| Drei Kundenprojekte sind offen | viele Karten in mehreren Spalten | welches Projekt heute Priorität hat |
| Ein Produktionsbug kommt rein | neue Karte „In Progress” | temporären Fokus ohne Verlust des alten Zustands |
| Eine Idee entsteht nebenbei | weiteres Backlog-Item | Ablage ohne sofortige Aufmerksamkeit |
| Ein Agent erzeugt einen Patch | Karte bewegt sich nicht von selbst sinnvoll | Review-Status, Kontext und nächste Entscheidung |
Kanban visualisiert Arbeit. Fokus-Management entscheidet, welche Arbeit gerade nicht sichtbar sein sollte.
Warum To-do-Apps nicht reichen
Apps wie Things, Todoist oder TickTick machen es einfacher, Aufgaben zu notieren als Kanban-Tools. Aber sie modellieren keine Projekte als Arbeitseinheiten mit eigenem Status. Eine Liste “Projekt Müller-Website” ist strukturell dasselbe wie eine Liste “Einkauf”. Der Unterschied liegt nur im Namen.
Was fehlt: ein Projekt, das einen Status hat (aktiv, geparkt, abgeschlossen), ein Board, wenn es gebraucht wird, und die Möglichkeit, zwischen Projektkontexten zu wechseln, ohne alles auf einmal zu sehen.
Das Überangebot an Notion
Notion ist das Gegenteil. Es kann alles, also wird alles gebaut: Projektverwaltung, Wiki, Meeting-Notizen, Habit-Tracker, Rezepte. Irgendwann hat man ein System, das mehr Pflege braucht als die eigentliche Arbeit.
Das ist kein Fehler von Notion — es ist der Preis von Flexibilität. Wer für sich selbst ein komplettes Projektmanagement-System in Notion aufbaut, hat ein Hobby, kein Werkzeug.
Was in der Praxis funktioniert
Die eigentliche Frage ist simpler: Welche Aufgaben habe ich pro Projekt, welche ist als nächstes dran, und was mache ich gerade? Alles andere — Gantt-Ansichten, Zeiterfassung, Dependency-Graphs — ist Overhead für eine Arbeitssituation, in der eine Person alle Rollen innehat.
Lokale Speicherung ist dabei kein nice-to-have. Wenn ein Task-Tool Cloud-Sync voraussetzt, hat man eine weitere Service-Abhängigkeit in der eigenen Produktivitäts-Infrastruktur. Das Tool geht offline? Pech. Der Anbieter stellt ein Feature ein? Datenmigration. Pricing ändert sich? Kündigen oder zahlen.
Lokale Daten bedeuten: das Tool funktioniert, solange der Rechner läuft.
Ein funktionierender Minimal-Workflow sieht so aus:
- Jedes Projekt hat einen aktiven Zustand: aktiv, geparkt, abgeschlossen.
- Pro Projekt gibt es wenige konkrete nächste Aufgaben, kein endloses Ideenlager.
- Eine Fokus-Ansicht zeigt nur das aktuelle Projekt und die nächste ausführbare Aufgabe.
- Unterbrechungen werden als Statuswechsel behandelt, nicht als neues Organisationsritual.
- Am Tagesende bleibt sichtbar, wo man wieder einsteigen muss.
Der letzte Punkt ist für Entwickler wichtiger als er klingt. Viele Produktivitätsverluste entstehen nicht beim Arbeiten, sondern beim Wiederfinden des Arbeitszustands nach Unterbrechungen.
KI-Agenten verschärfen das Problem
Mit KI-Assistenten entsteht eine neue Art von Parallelität. Während ein Agent Tests schreibt, recherchiert ein anderer eine Bibliothek, und im Hauptprojekt läuft noch ein Bugfix. Klassische Aufgabenlisten sind dafür zu grob, klassische Kanban-Boards zu flach.
Was zusätzlich gebraucht wird:
- Agenten-Ausgaben als prüfbare Aufgaben: Ein Patch ist nicht „done”, nur weil er erzeugt wurde. Er braucht Review, Test und Entscheidung.
- Kontextnotizen pro Projekt: Warum wurde ein Ansatz verworfen? Welche Datei darf nicht angefasst werden?
- Rückkehrpunkte: Wenn ein Agentenlauf abbricht oder ein Review offen bleibt, muss der nächste Schritt sichtbar sein.
Das ist kein Argument für mehr Tool-Komplexität. Es ist ein Argument für präzisere Zustände.
GitHub Issues und Projects als pragmatische Basis
Eine Ausnahme in dieser Betrachtung ist GitHub. Nicht weil GitHub Issues das perfekte Aufgabenmanagement wären, sondern weil sie für Entwickler bereits dort liegen, wo die Arbeit entsteht: im Repository, am Pull Request, am Commit, an der Diskussion über Code.
Für Solo-Entwickler ist das erstaunlich nah am Optimum. Ein Problem wird als Issue formuliert, ein Feature als abgrenzbare Aufgabe beschrieben, Labels quantifizieren Aufwand oder Risiko, Meilensteine bündeln Lieferstände. Aus einer diffusen Idee wird dadurch schnell eine Liste konkreter Arbeitspakete. Der wichtigste Punkt: Diese Liste ist nicht neben dem Code, sondern mit dem Code verbunden.
Mit KI-Assistenten wird dieser Vorteil größer. GitHub hat stabile Schnittstellen, die von Agenten gelesen und beschrieben werden können. Ein Agent kann aus einer Beschreibung ein Issue vorbereiten, offene Issues nach Labels filtern, eine Umsetzung vorschlagen, einen Branch erzeugen, einen Pull Request verknüpfen oder den nächsten Schritt aus einem Kommentar ableiten. Das macht Issues nicht automatisch zu guter Planung. Aber es macht sie zu einer sehr guten Arbeitsfläche für KI-unterstützte Entwicklung.
Der sinnvolle Workflow sieht eher so aus:
- Ideen und Fehler werden als Issues erfasst, nicht als lose Notizen.
- Labels beschreiben Art, Priorität, Aufwand oder Unsicherheit.
- Größere Themen bekommen ein Tracking-Issue, das Unteraufgaben und Repositories zusammenführt.
- GitHub Projects aggregiert diese Issues in eine projektübergreifende Ansicht.
- Zusätzliche Felder wie Status, Fokus, Bereich oder nächster Schritt machen aus der Liste ein steuerbares Dashboard.
Der unterschätzte Teil sind GitHub Projects. Sie müssen nicht an ein einzelnes Repository gebunden bleiben. Gerade bei mehreren eigenen Projekten kann ein Project Board die Gesamtübersicht liefern: Website, Tooling, kleine Open-Source-Pakete, Experimente, Wartung. Ein Tracking-Issue pro Thema oder Workflow kann Issues aus verschiedenen Repositories bündeln, automatisiert in ein Projekt übernehmen und dort mit Metadaten versehen werden. Dann entsteht nicht noch ein Board pro Repo, sondern eine zentrale Arbeitsansicht über alle Repos hinweg.
Das ist für Solo-Entwicklung praktischer als viele klassische Projektmanagement-Tools, weil es nicht vorgibt, ein Teamprozess zu sein. Es zeigt: Was ist offen? Was blockiert? Was lohnt sich? Was ist nur eine Idee? Und es bleibt anschlussfähig an die Werkzeuge, die ohnehin arbeiten: GitHub CLI, API, Actions, Pull Requests und KI-Agenten.
Die Schwäche liegt an anderer Stelle. GitHub ist hervorragend, wenn Arbeit aus Code heraus entsteht oder in Code zurückfließt. Es ist weniger gut als persönlicher Fokusraum. Es zeigt viel Kontext, aber nicht automatisch den richtigen. Wer sich morgens fragt, woran er heute sinnvoll weiterarbeitet, bekommt zwar Daten, aber nicht zwingend Ruhe. Genau an dieser Stelle beginnt der Unterschied zwischen Aufgabenverwaltung und Fokus-Management.
Das Problem mit “einem für alles”
Die Erwartung, ein Tool zu finden, das von der Daily-Notiz bis zum Jahres-Roadmap alles abbildet, ist das Problem. Das führt zu Notion-Monolithen und verlassenen Jira-Instanzen.
Realistischer ist ein klarer Scope: Projekte, Aufgaben, Status, Fokus-Ansicht. Nicht mehr. Alles, was darüber hinausgeht — Kommunikation, Zeiterfassung, Dokumentation, oder KI-gestützte Coding-Workflows wie Aider und Zed — gehört in spezialisierte Tools, die das besser machen.
Ordna versucht genau diesen Scope zu halten. Desktop-App, lokal, vier Status-Stufen, Kanban optional. Nicht als “Jira-Alternative für alle”, sondern als Werkzeug mit klar eingegrenztem Anspruch. Für jeden, der ein Projektmanagement-Tool sucht, das nicht zuerst ein Kollaborations-Tool ist.
Dabei ist Ordna noch im Aufbau. Im Kern ist es ein Versuch, Aufgaben und Fokus aus Sicht eines Solo-Entwicklers zu modellieren — und gleichzeitig eine praktische Übung mit Tauri. Ob daraus dauerhaft der Absprung von GitHub als Arbeitszentrale gelingt, ist offen. Die technische Hürde ist nicht das Problem. Die schwierigere Frage ist die KI-Integration: Sobald ein Open-Source-Tool Agenten wirklich sinnvoll anbinden soll, entstehen API-Kosten, Betriebsfragen und schnell ein Lock-in auf bestimmte KI-Anbieter. Für ein Nebenprojekt ist das kein kleines Detail, sondern ein eigener Produktbereich.
Der Vergleich, der am häufigsten passt: einfacher als Jira, mächtiger als eine To-do-App. Das ist keine Marketing-Überschrift, sondern die Beschreibung eines konkreten Anwendungsfalls — wer ihn hat, weiß es.
Wann Kanban trotzdem sinnvoll ist
Kanban ist nicht falsch. Es ist nur oft das falsche Zentrum. Sinnvoll bleibt es, wenn Aufgaben wirklich einen sichtbaren Fluss haben: Backlog, bereit, in Arbeit, Review, erledigt. Bei Kundenprojekten, Veröffentlichungen oder Agenten-Patches kann diese Sicht helfen.
Für Solo-Entwicklung sollte das Board aber eine Ansicht auf Arbeit sein, nicht das ganze System. Das Projekt, der aktuelle Fokus und der Wiedereinstiegspunkt sind wichtiger als die Spalte, in der eine Karte liegt.