Zurück zum Blog
Entwicklung16. Februar 20264 min readKrokanti Software

Warum wir unsere eigenen Tools gebaut haben, statt vorhandene zu nutzen

Wie die Entwicklung von k-notes, k-tasks und k-cv unsere Denkweise über Software verändert hat — und warum 'nutzt doch einfach ein vorhandenes Tool' nicht immer der richtige Rat ist.


Wir geben Kunden Ratschläge, wann sie individuelle Software entwickeln lassen sollten und wann vorhandene Tools die bessere Wahl sind. Es wäre unglaubwürdig, dieses Denken nicht auch auf uns selbst anzuwenden.

Als wir also entschieden, k-notes, k-tasks und k-cv zu bauen, kamen zu Recht kritische Fragen: Notion existiert. Trello existiert. Es gibt Dutzende Lebenslauf-Builder. Was hat euch bewogen, eigene Lösungen zu entwickeln?

Hier ist die ehrliche Antwort.

Wir wollten Tools, die so funktionieren, wie wir denken

Die meisten Produktivitätsprogramme sind für den Durchschnittsnutzer über alle denkbaren Anwendungsfälle hinweg konzipiert. Das ist eine vernünftige Produktstrategie. Sie bedeutet aber auch: viel Komplexität, die die meisten Menschen nie nutzen.

Wir notieren ständig Dinge — in Gesprächen, beim Lesen, wenn nachts um 23 Uhr eine Idee auftaucht. Wir wollten einen Editor, der sofort öffnet, automatisch speichert und nicht im Weg steht. Notion ist hervorragende Software, aber das ist es nicht. Jedes Dokument lebt in einem Workspace-System, das einen Moment Navigation erfordert. Wir griffen immer wieder nach einer Notiz-App, die sich öffnet wie eine leere Seite.

Also haben wir eine gebaut.

Dasselbe geschah mit Aufgaben. Wir nutzten jahrelang Trello. Dann Asana. Dann Linear. Jedes löste manche Probleme und schuf neue. Wir wollten ein Kanban-Tool, bei dem eine Aufgabe mit einem Klick angelegt ist, die Oberfläche keine Einarbeitung erfordert und die kostenlose Tarifstufe sich nicht wie ein getarnter Test anfühlt. Also haben wir das gebaut.

Uns liegt Dateneigentümerschaft am Herzen

Wir sind ein europäisches Unternehmen, und Datenpraktiken, die in Silicon Valley normal sind, sind hier — rechtlich wie ethisch — nicht immer akzeptabel. Wenn Sie ein kostenloses amerikanisches SaaS-Tool nutzen, ist das Geschäftsmodell in der Regel Werbung oder Datenlizenzierung. Ihre Notizen, Ihre Aufgaben, Ihre Karrieredokumente: Sie sind das Produkt.

Unsere Produkte laufen auf europäischer Infrastruktur (Neon Postgres mit EU-Datenhaltung), und wir haben ein einfaches Verhältnis zu unseren Nutzern: Sie zahlen eine faire Gebühr, wir speichern Ihre Daten, wir verkaufen sie nicht und werten sie nicht aus. DSGVO-Konformität ist für uns kein rechtliches Pflichtprogramm — sie ist die Designanforderung.

Software zu bauen macht Sie zu einem besseren Entwicklungspartner

Jedes Mal, wenn wir ein Produktfeature veröffentlicht haben, sind wir auf dieselben Probleme gestoßen, mit denen unsere Kunden konfrontiert sind: unklare Anforderungen, Scope Creep, die Spannung zwischen Geschwindigkeit und Qualität, Entscheidungen, die klein wirkten und sich als grundlegend erwiesen.

Eigene Produkte zu betreiben hat uns zu besseren Beratern gemacht. Wenn ein Kunde sagt "wir wollen nur noch eine Sache hinzufügen", wissen wir genau, was das für einen Zeitplan bedeutet. Wenn jemand nach Datenbankschema-Entscheidungen fragt, haben wir diese Gespräche geführt — nachts um zwei, beim Versuch, ein Produktionsproblem zu beheben.

Eigenes Risiko zu tragen verändert, wie man über Software nachdenkt.

Was wir gelernt haben (und was uns überrascht hat)

Das Schwierigste war nicht das Engineering. Es war zu entscheiden, was wir nicht bauen.

Jedes Produkt, das wir ausliefern, hat eine Liste von Features, die wir bewusst weggelassen haben. k-notes hat keinen Wiki-Modus. k-tasks hat kein Gantt-Diagramm. k-cv schreibt nicht mit KI Ihre Berufserfahrung. Nutzer fragen nach diesen Dingen. Wir sagen Nein.

Das ist schwerer, als es klingt. Der Instinkt, wenn jemand eine Funktion wünscht, ist Zustimmung. Nein zu sagen erfordert ein klares Bild davon, wofür das Produkt da ist — und die Bereitschaft, manche potenziellen Nutzer zu enttäuschen, um die eigentliche Zielgruppe besser zu bedienen.

Die Apps funktionieren wegen dem, was wir entfernt haben — nicht wegen dem, was wir hinzugefügt haben.

Warum wir Ihnen das erzählen

Wir erzählen diese Geschichte nicht, um zu suggerieren, dass individuelle Tools immer die richtige Wahl sind. Das sind sie nicht. Für die meisten alltäglichen Anforderungen gibt es hervorragende vorhandene Produkte — und diese zu nutzen ist meistens die vernünftigere Entscheidung.

Für uns war das Bauen eigener Tools aber keine Eitelkeit. Es war der einzige Weg, genau das zu haben, was wir brauchten, im Einklang mit unseren Werten, das wir selbst warten und weiterentwickeln können. Die Produkte existieren, weil wir sie nutzen — nicht als Portfolio-Übung.

Wenn Sie etwas aufbauen möchten und abwägen, ob Sie kaufen oder entwickeln sollen: Wir haben dazu eine klare Meinung und sagen Ihnen nicht einfach, was Sie hören wollen.