Leistung / Softwareentwicklung
Wir entwickeln Software, die genau den Ablauf abbildet, der dein Geschäft ausmacht — mit einem Zuschnitt, der nicht ausufert, und einer Übergabe, die dich nicht abhängig macht.
Individuelle Softwareentwicklung lohnt sich nicht, weil eigene Software schöner ist als gekaufte. Der stärkste Grund ist ein Ablauf, der anders funktioniert als der Ablauf, den jedes Standardprodukt unterstellt — und bei dem dieser Unterschied erklärt, warum Kunden bei dir kaufen. Daneben gibt es wenige weitere Gründe, die ebenfalls tragen: eine Klammer über mehrere Systeme, Zwischenlösungen, die zum System geworden sind, und eine Lizenzrechnung, die an der falschen Größe hängt. Der nächste Abschnitt geht sie einzeln durch. Alles darüber hinaus kauft man besser fertig. Diese Seite beschreibt, wie ich diese Grenze im Erstgespräch ziehe, wie ein Projekt geschnitten wird, damit es nicht ausufert, und was am Ende tatsächlich bei dir bleibt.
Individuelle Softwareentwicklung ist der Bau einer Anwendung, die auf einen konkreten Ablauf in einem konkreten Unternehmen zugeschnitten ist, statt einen Standardablauf zu unterstellen. Sie lohnt sich nicht, weil eigene Software schöner wäre als gekaufte, sondern wenn der eigene Ablauf von dem abweicht, den jedes fertige Produkt voraussetzt — und wenn genau diese Abweichung erklärt, warum Kunden bei dir kaufen. Weitere Anlässe, die tragen: eine Klammer über mehrere Systeme, Zwischenlösungen aus Tabellen und Skripten, die längst produktiv laufen, und eine Lizenzrechnung, die an einer Größe hängt, die nicht zum Nutzen passt. Der Zuschnitt zielt auf eine früh benutzbare erste Version statt auf einen späten Vollausbau. Repository, Historie und die ausschließlichen Nutzungsrechte an der Individualentwicklung liegen dabei von Anfang an beim Auftraggeber, und die Infrastruktur läuft ab dem ersten Tag auf dessen eigenen Konten. Alles, was ein Standardprodukt genauso gut abdeckt, kauft man besser fertig — diese Grenze ziehen wir im Erstgespräch, nicht im Angebot.
Es gibt vier Muster, bei denen eigene Software die bessere Entscheidung sein kann. Sie haben alle damit zu tun, dass ein fertiges Produkt dich zwingen würde, deine Arbeit an seine Annahmen anzupassen.
| Anlass | Woran er erkennbar ist |
|---|---|
| Der Ablauf ist der Wettbewerbsvorteil | Der eigene Ablauf weicht von dem ab, den jedes Standardprodukt unterstellt — und diese Abweichung erklärt, warum Kunden kaufen |
| Zwischenlösungen sind zum System geworden | Tabellen und Skripte laufen längst produktiv, ohne dass jemand sie so geplant hat |
| Mehrere Systeme tragen einen Ablauf | Es fehlt die Klammer, die den gemeinsamen Ablauf über die Systemgrenzen hinweg trägt |
| Lizenzkosten wachsen falsch | Die Rechnung hängt an einer Größe, die nicht zum tatsächlichen Nutzen passt |
Wenn deine Kunden dich wegen einer bestimmten Art der Abwicklung wählen — einer schnelleren Kalkulation, einer besonderen Prüfung, einer Kombination aus Leistungen, die sonst niemand so anbietet —, dann ist genau dieser Teil in keinem Standardprodukt vorgesehen. Man kann ihn dort nachbauen, aber immer nur als Umweg. Umwege sind teuer, weil sie jeden Mitarbeiter jeden Tag Zeit kosten.
Ein verlässliches Signal ist eine Tabelle, die niemand mehr löschen darf. Daneben stehen dann eine zweite Tabelle, ein geteilter Ordner, eine Handvoll Regeln im Postfach und eine Person, die weiß, wie alles zusammenhängt. Das funktioniert, bis diese Person im Urlaub ist oder das Volumen sich verdoppelt. Eigene Software macht aus dieser stillen Absprache ein Werkzeug mit Regeln, Rechten und Nachvollziehbarkeit.
CRM, Warenwirtschaft, Buchhaltung und Projektwerkzeug decken je einen Ausschnitt ab. Der Ablauf, der dein Geschäft ausmacht, läuft quer darüber. Eine eigene Anwendung kann diese Klammer sein: Sie führt die Daten zusammen, hält den Stand fest und schreibt gezielt in die Systeme zurück, statt sie zu ersetzen.
Manche Produkte rechnen pro Nutzer ab, obwohl in deinem Fall die Zahl der Vorgänge wächst und nicht die Zahl der Mitarbeiter. Dann steigen die Kosten an einer Achse, die mit deinem Nutzen nichts zu tun hat. Das ist ein legitimer wirtschaftlicher Grund für eigene Software — aber er will gerechnet werden, nicht gefühlt.
Das sage ich lieber vor dem Projekt als danach. Vieles, was ein Unternehmen an Software braucht, ist zu Recht gekauft, und ein Individualprojekt an der falschen Stelle bindet Geld und Aufmerksamkeit, die woanders mehr bewirkt hätten.
Das teuerste Risiko in einem Individualprojekt ist nicht die Technik, sondern ein Umfang, der während der Umsetzung wächst, weil jede beteiligte Abteilung ihre Sonderfälle nachreicht. Dagegen hilft kein Vertrag, sondern ein Schnitt, der von Anfang an klarstellt, was in der ersten Version nicht enthalten ist.
Der Einstieg ist deshalb die kleinste Version, die einen vollständigen Ablauf trägt — nicht ein Prototyp, der nur die Hälfte kann, und nicht ein Vollausbau, der alles kann und nie fertig wird. Ein Vorgang muss von Anfang bis Ende durchlaufen können, für eine benennbare Gruppe von Nutzern, mit echten Daten. Alles, was diesen einen Durchlauf nicht braucht, wandert auf eine sichtbare Liste für später.
Drei Fragen entscheiden diesen Schnitt: Welcher Ablauf kostet heute am meisten Zeit oder verursacht die teuersten Fehler? Welche Nutzergruppe arbeitet als Erste damit? Und welche Sonderfälle darf die erste Version bewusst an einen Menschen abgeben, statt sie zu automatisieren? Vor allem die dritte Frage wirkt direkt auf den Umfang: Ein Ausnahmefall, der zehnmal im Jahr vorkommt, braucht keine eigene Funktion, sondern eine klare Stelle, an der jemand eingreift.
Danach wird in kurzen Abständen geliefert. Nicht, weil das Vokabular gerade modern ist, sondern weil du in einer benutzbaren Umgebung Dinge siehst, die in keinem Konzept auffallen — Felder, die in der Praxis leer bleiben, Schritte in der falschen Reihenfolge, eine Regel, die im Alltag drei Ausnahmen hat.
Eigene Software ist keine Leistung, die man abgibt und abholt. Vier Dinge kann ich nicht liefern, und sie entscheiden über das Ergebnis mehr als jede technische Entscheidung.
Wie jemand arbeitet, sieht man am besten an etwas, das man selbst prüfen kann. Diese Website ist ein solches Beispiel. Sie ist keine Vorlage aus einem Baukasten, sondern in TypeScript geschrieben und läuft mit React Server Components: Der Seiteninhalt wird auf dem Server gerendert und kommt als fertiges HTML beim Browser an. Interaktive Teile wie das Kontaktformular sind eigene Client-Komponenten — auch sie stehen schon im ausgelieferten HTML; JavaScript wird nur für diese Teile geladen und macht sie nachträglich bedienbar. Der Browser muss also kein Programm ausführen, um den Inhalt anzuzeigen.
Ausgeliefert wird sie über Cloudflare Workers, also nah am Besucher statt aus einem einzelnen Rechenzentrum. Die Inhalte des Blogs liegen in einer PostgreSQL-Datenbank bei Supabase; die Seiten lesen sie direkt über deren HTTP-Schnittstelle, ohne eine weitere Zwischenschicht. Was von außen hereinkommt, wird vorher gegen ein festgelegtes Schema geprüft: die Studio- und MCP-Verträge mit Zod, der Blog-Eingang mit einem eigenen Validator, der jedes Feld eines Artikels einzeln durchgeht.
Auch der automatische Weg eines Artikels in den Blog ist mit Kontrollen bestückt. Jeder Entwurf durchläuft einen Schreib- und einen Prüfdurchgang, muss den festen Artikelvertrag samt bestandenem QA-Bericht erfüllen, und die Datenbank wiederholt die entscheidenden Prüfungen — Status, Quellen, Slugs, Linkziele — noch einmal in derselben Transaktion, in der der Entwurf gespeichert wird. Erst danach schaltet ein nachgelagerter Auslöser genau diesen geprüften Entwurf öffentlich. Am Code selbst hängen Linter, Typprüfung und eine Testreihe, die die Seite vollständig baut und anschließend das ausgelieferte HTML und die strukturierten Daten gegenprüft.
Der Punkt daran ist nicht die Auswahl der Werkzeuge — andere Kombinationen sind genauso vertretbar. Der Punkt ist, dass jede Entscheidung darin einen nennbaren Grund hat und dass der Zustand des Systems messbar ist, statt auf Zuruf zu beruhen. Genau das erwarte ich von Software, die ich übergebe: Sie muss sich nachvollziehen lassen, auch von jemandem, der sie nicht geschrieben hat.
Die wichtigste Frage in einem Individualprojekt wird oft zu spät gestellt: Wem gehört am Ende was? Sie gehört in den Vertrag, bevor gebaut wird, und sie hat drei Teile.
Der Quellcode. An der Individualsoftware, die du bezahlst, bekommst du die ausschließlichen Nutzungsrechte — zeitlich, räumlich und inhaltlich unbeschränkt, samt dem Recht, sie ohne Rückfrage zu ändern und von jemand anderem weiterentwickeln zu lassen. Das Urheberrecht selbst ist nach deutschem Recht nicht übertragbar (§ 29 UrhG); übertragen werden diese Nutzungsrechte, und sie decken alles ab, was du mit der Software vorhast. Der Code liegt von Anfang an samt Historie in einem Repository unter deinem Konto, nicht in meinem. Das ist keine Geste, sondern die einzige Bauform, in der eine Zusammenarbeit ohne Druckmittel funktioniert.
Die Zugänge und die Infrastruktur. Datenbank, Hosting, Domain und Schlüssel laufen auf deine Konten. Ich bekomme Zugriff, solange ich betreue, und du behältst die Möglichkeit, ihn zu entziehen. Alles andere ist eine Abhängigkeit, die erst dann sichtbar wird, wenn man sie beenden will.
Fremdbestandteile. Individualsoftware besteht nie nur aus eigenem Code. Open-Source-Bibliotheken, bezahlte Dienste und Schnittstellen bringen eigene Lizenzen und Kosten mit. Was davon verwendet wird, gehört in eine Liste, die du bekommst — samt der Angabe, welche laufenden Kosten daran hängen und welcher Dienst im Zweifel ersetzbar ist.
Zur Ehrlichkeit gehört auch die Kehrseite: Eine Abhängigkeit verschwindet nicht dadurch, dass der Code dir gehört. Wer eine Anwendung geschrieben hat, kennt sie besser als jeder Nachfolger. Reduzieren lässt sich das nur durch verbreitete Technik statt exotischer Speziallösungen, durch Dokumentation, die den Zweck erklärt und nicht die Syntax, und durch Tests, die einem Nachfolger sagen, ob seine Änderung etwas kaputt gemacht hat.
Der Tag, an dem eine Anwendung produktiv geht, ist nicht das Ende des Projekts, sondern der Anfang ihrer Lebensdauer. Software altert auch dann, wenn niemand sie anfasst: Bibliotheken bekommen Sicherheitsupdates, Schnittstellen von Fremdsystemen ändern sich, Zertifikate laufen ab, Datenmengen wachsen über die Annahmen hinaus, unter denen die erste Version gebaut wurde.
Deshalb gehört zur Übergabe mehr als ein Zugang: eine Beschreibung, was das System tut und für wen; die benannte Person, die auf deiner Seite verantwortlich ist; die Antwort auf die Frage, was zu tun ist, wenn es nicht erreichbar ist; und eine geprüfte Sicherung, von der jemand tatsächlich einmal zurückgespielt hat. Eine Sicherung, die nie getestet wurde, ist eine Vermutung.
Für den Betrieb danach gibt es drei ehrliche Wege, und keiner davon ist für jeden richtig. Du betreibst selbst, wenn du jemanden im Haus hast, der Updates und Störungen übernehmen kann. Du buchst eine Betreuung mit klar beschriebenem Umfang, wenn du das nicht hast — dann gehören Reaktionszeiten, Updates und der Umgang mit Weiterentwicklungswünschen ausdrücklich hinein. Oder du übergibst an einen anderen Dienstleister; auch das muss möglich sein, ohne dass etwas zurückgehalten wird. Welchen Weg du wählst, entscheidest du am besten vor dem Projekt, denn er beeinflusst, wie gebaut wird.
Drei Projekte aus der Praxis. Wir nennen Branche und Größe, keine Namen und keine Orte — so braucht keiner unserer Auftraggeber eine Freigabe zu erteilen, damit wir über die Arbeit sprechen können. Die Zahlen stammen aus Messungen im laufenden Betrieb; wie gemessen wurde und was die Zahl nicht belegt, steht jeweils dabei.
Ausgangslage. Aus dem Erstgespräch: „Unsere Aufträge liegen verteilt in E-Mails, Excel-Listen und PDF-Dateien. Wir müssen ständig nachfragen, wer gerade dran ist, welche Unterlagen fehlen und ob ein Auftrag schon abgerechnet wurde. Dieselben Kundendaten tippen wir dabei mehrfach ein.“
Gebaut. Eine zentrale webbasierte Auftragsverwaltung mit Kunden- und Auftragsdatenbank, gemeinsamem Statusmodell und Benutzerrollen. Dazu Dokumentenablage, interne Kommentare, Aufgaben und eine Suche mit Filtern; fehlende Unterlagen werden über Checklisten sichtbar und erinnert, ein Dashboard zeigt offene und überfällige Vorgänge, wiederkehrende Dokumente entstehen aus den vorhandenen Auftragsdaten. Freigegebene Abrechnungsdaten gehen an die bestehende Buchhaltungssoftware. Die Excel-Bestände wurden bereinigt und migriert, inklusive Dublettenprüfung und Testimport; Hosting, Monitoring, Backups und eine Wiederherstellungsprüfung gehörten dazu.
Bemerkenswert. Ein spürbarer Teil des Projekts war keine Programmierarbeit: das Abstimmen der bislang uneinheitlichen Statusbezeichnungen und die Schulung des Teams.
Ergebnis. Die aktive administrative Bearbeitungszeit je Auftrag sank von 22 auf 8 Minuten. Bei 450 Aufträgen im Monat ergibt das 450 × (22 − 8) ÷ 60 = 105 Stunden monatlich. Gemeint sind Erfassung, Datenübernahme, Dokumentenzuordnung und interne Weitergabe — nicht die eigentliche Dienstleistung und nicht die gesamte Durchlaufzeit.
Wie gemessen wurde. Aktive Bearbeitungszeit vergleichbarer Aufträge vor und nach der Einführung, je 50 Vorgänge, mit gleichem Mix aus einfachen und komplexen Aufträgen und mitgezählten Nacharbeiten; das Monatsvolumen stammt aus den Unternehmensdaten, Systemzeitstempel dienten nur zur Ergänzung, für sich genommen belegen sie keine eingesparte Arbeitszeit.
Dauer. Rund zehn Wochen bis zur ersten produktiven Version — zwei Wochen Prozess- und Datenmodell, sechs Wochen Entwicklung, zwei Wochen Migration, Test und Einführung.
Stunden und Material wurden nach dem Einsatz auf Zettel notiert oder als Foto per Messenger geschickt, im Büro musste danach rekonstruiert werden, was zu welchem Auftrag gehört und was fehlt. Eine mobile Webanwendung bündelt jetzt Arbeitszeiten, Material, Fotos und Leistungsbeschreibung in einem zusammengehörigen Bericht, mit Pflichtfeldern und Plausibilitätsprüfungen, lokal zwischengespeicherten Entwürfen samt erkennbarem Synchronisationsstatus für Einsätze mit schlechter Verbindung, optionaler Kundenbestätigung und einem einheitlichen PDF. Bei einzeln abrechenbaren Pflege- und Zusatzaufträgen sank die mediane Zeit vom Einsatzende bis zum vollständigen, geprüften Leistungsnachweis von 6 auf 1 Werktag; die Abrechnungsgrundlage liegt damit typischerweise 5 Werktage früher im Büro. Das beschreibt weder fünf eingesparte Arbeitstage noch einen nachgewiesen früheren Zahlungseingang. Das Buchhaltungsprogramm blieb bestehen, freigegebene Nachweise werden an die vorhandene Abrechnung exportiert; Tourenoptimierung, Lohnabrechnung und eine vollständige Warenwirtschaft waren nicht Teil des Projekts.
Die Messmittel standen in einer Excel-Liste, die Nachweise lagen in verschiedenen Ordnern; wo ein Gerät gerade ist und wann es wieder kalibriert werden muss, war nicht zuverlässig erkennbar. Eine webbasierte Prüfmittelverwaltung führt Gerätebestand, Seriennummern, Standorte und Verantwortliche zusammen, verknüpft die zugehörigen Nachweise, macht sie per QR-Etikett am Arbeitsplatz aufrufbar, erinnert an fällige Kalibrierungen und sperrt Geräte mit abgelaufenem Nachweis, sodass sie nicht mehr als freigegebenes Prüfmittel erscheinen. Im Bestand von 240 Prüfmitteln ging die Zahl überfälliger Kalibrierungen von 18 auf 4 zurück, von 7,5 % auf rund 1,7 % des Bestands; die vier verbleibenden Geräte waren als gesperrt gekennzeichnet und warteten auf die externe Kalibrierung. Dieser Rückgang beruht auf der Kombination aus besserer Übersicht, verbindlichen Zuständigkeiten und nachgeholten Kalibrierungen — nicht auf der Software allein. Die Software legt auch keine fachlichen Intervalle fest und ersetzt keine Kalibrierung, und eine Systemsperre verhindert nicht die physische Nutzung; dafür wurde der betriebliche Kennzeichnungs- und Sperrprozess mit festgelegt.
Das hängt am Zuschnitt, nicht an einer Preisliste. Entscheidend sind die Zahl der Abläufe, die die erste Version tragen muss, die Zahl und Qualität der Schnittstellen zu Bestandssystemen und die Frage, wie viele Sonderfälle automatisiert statt an einen Menschen abgegeben werden. Eine belastbare Zahl entsteht nach dem Gespräch, in dem wir den Ablauf durchgehen — jede Zahl davor ist geraten.
Den Rahmen nenne ich nach der Diagnose, weil er an zwei Dingen hängt, die nicht in meiner Hand liegen: wie schnell Zugänge und echte Testdaten bereitstehen und wie schnell auf deiner Seite entschieden wird. Der Schnitt zielt bewusst auf eine früh benutzbare Version statt auf eine späte vollständige.
Ja. Repository und Historie liegen auf deinem Konto, und an der Individualentwicklung erhältst du die ausschließlichen, unbeschränkten Nutzungsrechte — einschließlich Änderung und Weiterentwicklung durch Dritte. Die Infrastruktur läuft von Anfang an auf deinen Konten. Verwendete Open-Source-Bibliotheken behalten ihre eigenen Lizenzen — welche das sind, steht in der Übergabe.
Ja. Am Anfang steht dann eine nüchterne Bestandsaufnahme: Struktur und Zustand des Codes, Abhängigkeiten mit Sicherheitslücken, vorhandene Tests, Zustand der Datenbank und die Frage, ob Weiterbauen oder ein gezielter Neubau einzelner Teile günstiger ist. Das Ergebnis kann auch lauten, dass der Bestand bleibt und nur eine Lücke geschlossen wird.
Wo es den Ablauf messbar verbessert, ja — etwa beim Einordnen, Extrahieren oder Vorformulieren. Ein Sprachmodell bekommt dabei einen definierten Eingang, sein Ergebnis wird geprüft, und es gibt eine festgelegte Stelle, an der ein Mensch übernimmt. KI-Showcases ohne produktiven Nutzen baue ich nicht.
Ich. GlobalNet Strategies ist seit Juli 2023 operativ tätig und founder-geführt: Du sprichst im Erstgespräch mit derselben Person, die später die Lösung entwirft, baut und verantwortet. Das begrenzt, wie viele Projekte gleichzeitig laufen können — es ist der Grund für den Zuschnitt auf die erste produktive Version und dafür, dass ich absage, wenn ein Standardprodukt die bessere Antwort ist.
Die Arbeitsweise in drei Schritten, hier auf Individualentwicklung angewendet: erst verstehen, dann bauen, dann betreiben.
Wir gehen den Ablauf durch, der die Software braucht: Wer arbeitet damit, welche Daten liegen wo, welche Regeln gelten wirklich — und welche stehen nur im Handbuch. Am Ende steht ein Zuschnitt, der klar sagt, was die erste Version kann und was bewusst noch nicht.
Gebaut wird in kurzen Abständen und gegen echte Daten, nicht gegen Wunschdaten. Du bekommst früh eine benutzbare Umgebung, in der deine Leute den Ablauf einmal komplett durchspielen — lange bevor irgendetwas produktiv Entscheidungen auslöst.
Wir schalten produktiv, beobachten Fehler und Nutzung und bauen dort aus, wo der Alltag es zeigt. Zur Übergabe gehören Quellcode, Zugänge, Dokumentation und eine ehrliche Antwort auf die Frage, wer das System morgen weiterentwickeln kann.
Dein nächster Schritt
Beschreib mir kurz, was dein Team gerade mit Tabellen, Zurufen und Zwischenlösungen zusammenhält. Ich sage dir offen, ob dafür eigene Software nötig ist — und wenn ein Standardprodukt reicht, sage ich auch das.