Individualsoftware-Entwicklung

Individualsoftware-Entwicklung — wir bauen die Software, die euer Geschäft braucht und die es als Standardprodukt nicht gibt. Vom kleinen Helferlein (ein 380-Zeilen-Daemon, der einen Webshop härtet) bis zum komplexen produktiven System (eine 100 000-Zeilen-Event-getriebene Decision-Plattform). Dieselbe Engineering-Disziplin, auf das Problem skaliert.

Wir arbeiten nach den Praktiken von Extreme Programming (XP) — fokussiert auf das, was tatsächlich funktionierende Software hervorbringt: Pair Programming, Test-Driven Development, Continuous Integration, Refactoring und direkte Kunden- Kollaboration. Nicht die zeremoniell überfrachteten Verwandten (Scrum, SAFe, …), bei denen die Rituale wichtiger werden als der laufende Code.

  flowchart LR
    A[Reales Problem] --> B[Discovery + Pair-Design]
    B --> C[1-2-Wochen-Iteration]
    C --> D[Getesteter Release]
    D --> E{"Löst es?"}
    E -->|noch nicht| B
    E -->|ja| F[Produktiv-Übergabe]
    D -.->|jede Änderung| G[TDD · CI · Refactor]

Worum es geht

Standardsoftware deckt seit Jahrzehnten die offensichtlichen 80 % der Geschäftsbedürfnisse ab. Was übrig bleibt, sind die 20 %, die für eure Organisation spezifisch sind — die Workflows, für die niemand ein SaaS verkauft, die Integrationen zwischen zwei Anbietern, die nicht miteinander reden wollen, die operativen Tools, die die Arbeit automatisieren, von der niemand ausserhalb der Firma weiss, dass ihr sie tut.

Diese 20 % sind das Feld der Individualsoftware-Entwicklung. Es ist auch das Feld, auf dem die meisten Software-Projekte scheitern — nicht weil die Technologie falsch ist, sondern weil der Prozess zum Ritual wird und der laufende Code zur Nebensache.

Wir bauen diese 20 %. Kleine Helferlein, wenn das gebraucht wird, komplexe Systeme, wenn das gebraucht wird. Dieselbe Engineering-Disziplin, kein zeremonieller Overhead.

Warum XP, nicht Scrum

Ihr braucht keine Übersicht aller Agile-Geschmacksrichtungen. Die Kurzversion:

• Extreme Programming (XP) fokussiert auf die Engineering-Praktiken, die direkt funktionierende Software hervorbringen: TDD, Pair Programming, Continuous Integration, Refactoring, Kunden-Kollaboration, kleine Releases.
• Scrum, SAFe und Konsorten fokussieren auf den Prozess rund um das Engineering: Zeremonien, Story Points, Velocity-Charts, Retrospektiven, Planungs-Rituale, „Agile-Coach"-Rollen.

In einer gesunden Organisation produzieren die Engineering- Praktiken den Wert und der Prozess ist leichtes Gerüst drumherum. In vielen Organisationen wird der Prozess zur Religion und das Engineering zur Nebensache. Statusberichte gehen vor laufendem Code; Zeremonien füllen den Kalender, während das System verrottet.

Wir arbeiten den XP-Weg:

• Pair Programming (oder Pair-Review von KI-augmentiertem Code) ist der Default. Zwei Köpfe an jeder substantiellen Änderung.
• TDD — Tests zuerst geschrieben, dann der Code. Der Test ist die Spezifikation, die lange nach den Meeting-Notizen noch da ist.
• Continuous Integration — jede Änderung geht durch dieselbe Pipeline. Kein „aber auf meiner Maschine funktioniert es".
• Refactoring ist Teil der Arbeit, kein separater Budgetposten. Sauberer Code ist günstiger zu erweitern als schmutziger Code.
• Kleine Releases — wöchentlich deploybare Artefakte, keine Quartals-Big-Bangs.
• Customer-on-site — euer Stakeholder ist kontinuierlich im Loop, nicht nur bei Sprint-Reviews.

Spektrum der Engagements

Dieselbe Methodik skaliert von Einzeiler-Utilities bis zu Multi-Daemon-Produktiv-Systemen. Beispiele aus unserem eigenen Portfolio illustrieren die Bandbreite:

• Kleine Helferlein (Tage bis Wochen). Ein 380-Zeilen- Perl-Daemon ( Abusive HTTP Watch), der Webshops gegen angreifenden Traffic härtet. In rund zwei Wochen gebaut. In Produktion bei mehreren Shops, seit über einem Jahr keine Änderungen nötig.
• Mittlere Systeme (Wochen bis wenige Monate). Eine privacy-wahrende Notification-Capture-App ( Notification Guard) — Tauri + Rust + Svelte, rund 10 000 Zeilen. In rund vier Wochen fokussierter Arbeit gebaut.
• Komplexe Produktiv-Systeme (Monate). Eine Echtzeit- Event-getriebene Decision-Plattform ( Realtime Decision Platform) — rund 100 000 Zeilen Python, sieben Daemons, ML-Pipeline, multi-tenant. Über rund sechs Monate gebaut.

Dieselbe Disziplin, dieselben XP-Praktiken, verschiedene Größenordnungen.

Was du bekommst

• Laufende Software früh. Innerhalb der ersten 1–2 Wochen eines Engagements läuft getesteter Code, der etwas Nützliches tut — nicht nur Folien und Architektur-Diagramme.
• Wöchentliche getestete Releases. Jede Woche endet mit deploybarem, getestetem Code. Du kannst das Engagement zu jeder Woche stoppen, und was da ist, ist produktionsreif.
• Volles Eigentum am Ende. Quellcode, Tests, Dokumentation, Deployment-Runbooks — alles deins. Keine Lizenzgebühren, keine Per-Seat-Kosten, kein Vendor-Lock-in zu uns.
• KI-unterstützte Produktivität. 8–12× der Durchsatz konventioneller Entwicklung, bei intakter Review-Disziplin und Audit-Trail. Der Code wird von einem Menschen geprüft; die KI ist Werkzeug, nicht Autor.
• Festpreis-MVP, dann iterative Erweiterung. Der erste Scope ist Festpreis, also kennst du das Budget. Danach werden Erweiterungen je Iteration gescopt, jede mit eigenem Preisschild.

Warum das ein CEO-Thema ist

• 💰 Build vs. Buy. Welche 20 % zu bauen statt zu kaufen, ist eine strategische Entscheidung. Die falschen Sachen zu bauen ist teuer; die Sachen zu kaufen, die ihr bauen solltet, ist auch teuer. Eine Funktion, die gut baut, ist die Funktion, die „bauen" zu einer glaubwürdigen Option im Build-vs.-Buy-Gespräch macht.
• 📈 Ausfallquoten. Industriedaten: ~60–70 % der Bespoke-Software-Projekte scheitern oder werden eingestellt. Der dominante Grund ist Prozess-Kollaps, keine technische Unmöglichkeit. Engineering-Disziplin adressiert genau diesen Grund.
• ⏱️ Time-to-Value. Eine sechsmonatige „Agile- Transformation" bevor der erste laufende Code gebaut ist, sind sechs Monate Opportunitätskosten. XP liefert laufenden Code in Woche eins.
• 🛡️ Kontinuität. Software, gebaut ohne Zeremonien aber mit Tests, Refactoring und klarem Code, ist Software, die ein Nachfolge-Team pflegen kann. Software, gebaut mit viel Zeremoniell und ohne Tests, ist Software, die am ersten Tag schon Legacy ist.
• 🔓 Eigentum. Ihr besitzt den Code, die Tests, die Dokumentation. Keine Per-Seat-Lizenzierungs-Schleichkosten, keine Vendor-Entscheidung über eure Roadmap, kein Risiko, dass der Lieferant insolvent geht oder strategisch abdreht.
• 🤖 KI ist Multiplikator, kein Autor. Das Produktivitäts- Argument für In-house-Build funktioniert nur, wenn die Produktivität real ist. KI-augmentiertes Engineering mit Disziplin gibt messbar 8–12×; KI ohne Disziplin gibt plausibel aussehenden Code, der nicht läuft.

Technologisches Fundament

Wir arbeiten in Sprachen und Stacks, die nach Passung gewählt werden, nicht nach Mode. Der richtige Stack wird durch das Problem und eure bestehende Landschaft bestimmt, nicht durch das, was die Beratung zufällig kennt.

Meld dich, dann skizzieren wir ein MVP — ein kleines Festpreis- Erststück — in einem Scoping-Gespräch.