Wann Individualsoftware Sinn ergibt
Nicht jedes Problem verlangt nach Individualsoftware. Die meisten betrieblichen Aufgaben lassen sich mit einer vernünftigen Standardlösung abdecken, und das ist auch gut so. Aber es gibt Situationen, in denen Standard einfach nicht geht.
Typische Anzeichen, dass du Individualsoftware brauchst:
- Du hast drei, vier verschiedene Standardprodukte angeschaut, und jedes deckt ungefähr 60 Prozent ab, aber nicht dieselben 60 Prozent.
- Die Software, die am besten passt, kostet in der richtigen Ausbaustufe mehr, als dein Budget zulässt, und die günstigere Variante bringt genau die Features nicht mit, die du brauchst.
- Dein Prozess hat sich über Jahre in deiner Firma eingespielt, und du willst ihn nicht zugunsten einer Standardsoftware umbiegen, weil er nachweislich funktioniert.
- Du wirst bei jedem Standard-Produkt gezwungen, Felder zu füllen und Menüs zu bedienen, die mit deinem Arbeitsalltag nichts zu tun haben.
- Die Software, die du heute nutzt, ist ein Excel-Monster, das über Jahre gewachsen ist und langsam zerbricht.
Was “schlank” konkret heisst
Individualsoftware ist nicht gleichbedeutend mit Mega-Projekt. Im Gegenteil: die Stärke einer individuellen Lösung liegt genau darin, dass sie nur das macht, was sie soll. Kein 400-Seiten-Handbuch, kein Admin-Panel mit 90 Einstellungen, kein Rollensystem für 15 Nutzertypen, wenn es um drei geht.
Mein Ansatz: je weniger, desto besser. Eine Anwendung sollte so einfach sein, dass ein neuer Mitarbeiter nach fünf Minuten Einweisung damit arbeiten kann. Jedes Feature, das nicht täglich oder wöchentlich gebraucht wird, wird weggelassen oder versteckt. Keine Konfigurationsoptionen, für die sich niemand je interessiert. Keine Theme-Wahl, kein eingebauter Chat, kein Newsletter-Modul.
Das Ergebnis sieht oft ungewöhnlich nüchtern aus. Das ist Absicht. Werkzeuge sollen wie Werkzeuge aussehen, nicht wie Consumer-Apps.
Technischer Baukasten
Ich bin nicht an einen einzelnen Stack gebunden und wähle nach dem Projekt. Ein paar Faustregeln:
- Python mit FastAPI oder Django, wenn es um Datenverarbeitung, ERP-Anbindung oder schnelle Prototypen geht. Python ist die erste Wahl, weil die meisten Bibliotheken existieren, die man in einem Schweizer KMU-Kontext braucht, von PDF-Generierung bis Swissdec-Export.
- TypeScript mit Node.js für API-lastige Backends, bei denen die Integration mit Frontend-Code eng sein muss.
- Svelte oder Vanilla-JS für Frontends. Ich baue keine React-Maschinen für interne Tools, wenn es auch mit einem schlankeren Framework geht. Svelte liefert denselben Nutzen mit einem Bruchteil der Komplexität.
- SQLite oder PostgreSQL für Datenhaltung. SQLite ist überraschend oft genug, gerade für interne Tools mit einer Handvoll Nutzern. PostgreSQL nehme ich, wenn es grösser wird oder bereits Teil der Infrastruktur ist.
- Docker für Deployment, wenn die Umgebung es zulässt. Macht Wartung und Umzug später einfacher.
Ich mache keine Dogmen aus der Tech-Wahl. Wenn deine IT PHP-Umgebung hat und den Code später selber pflegen will, schreibe ich PHP. Wenn deine Firma Microsoft-nah ist und eine .NET-Lösung praktischer passt, dann .NET. Das Werkzeug folgt dem Auftrag, nicht umgekehrt.
Wie das Projekt abläuft
Individualsoftware ist ein risikoreicheres Projekt als eine Standardinstallation, weil ein grösserer Teil davon am Anfang unklar ist. Deshalb baue ich immer in kleinen Stufen:
Phase 1, Kern (rund ein Drittel des Gesamtbudgets) Die absolute Grundfunktion. Ein Nutzer kann sich einloggen, den wichtigsten Datensatz erfassen und wieder ansehen. Nichts Schickes. Aber du kannst es ausprobieren und siehst, ob die Grundidee aufgeht.
Phase 2, Arbeitsfähig (rund ein Drittel) Jetzt wird die Anwendung so ergänzt, dass sie den geplanten Haupt-Workflow abbildet. Hier werden die realistischen Anforderungen sichtbar, die in der Planung noch abstrakt waren. Oft ändern wir hier noch Dinge, weil sich Annahmen als falsch herausstellen. Das ist normal und billiger als ein komplettes Redesign am Ende.
Phase 3, Produktiv (rund ein Drittel) Die letzten Feinheiten: Berechtigungen, Fehlerbehandlung, Backup, Monitoring, Dokumentation, Schulung für die Nutzer. Das sind die Themen, die oft unterschätzt werden, aber über die Akzeptanz entscheiden.
Nach jeder Phase schauen wir gemeinsam, ob die Richtung noch stimmt. Wenn nicht, justieren wir. Es gibt keinen Vertrag, der dich zwingt, sechs Monate lang an einem Plan festzuhalten, der nach zwei Monaten offensichtlich falsch ist.
Was du am Ende bekommst
- Quellcode in einem Git-Repository. Dein Eigentum. Wenn du mich morgen nicht mehr haben willst, nimmst du den Code und arbeitest mit jemand anderem weiter.
- Ein lauffähiges System auf deiner Infrastruktur oder auf einem Server deiner Wahl. Kein Cloud-Zwang, wenn du keinen willst.
- Dokumentation für Nutzer (kurz, mit Screenshots) und für Entwickler (Architektur, Deployment, Datenmodell).
- Eine Einweisung für die Leute, die damit arbeiten werden. Live, nicht nur als Video.
- Ein Wartungskonzept, ob ich das weiterführe oder du es intern übernimmst, bleibt dir überlassen.
Wann du mich nicht fragen solltest
Wenn es für dein Problem ein ausgereiftes Standardprodukt gibt, das mehr als 80 Prozent abdeckt und in deinem Budget liegt, nimm es. Individualsoftware zu bauen, wo eine bestehende Lösung ausreichen würde, ist Geldverbrennung. Ich sage dir das im Erstgespräch, und wenn ich ein passendes Standardprodukt kenne, nenne ich es.
Wann du mich kontaktieren solltest
- Du hast bereits Standardprodukte evaluiert und keines passt
- Du arbeitest aktuell mit einem Excel-Monster, das instabil ist
- Dein Prozess ist speziell und soll auch speziell bleiben, weil er dein Wettbewerbsvorteil ist
- Du willst ein internes Tool, das dein Team entlastet, ohne gleich ein Enterprise-Projekt aufzuziehen