Webbasierte Anwendungen für individuelle Anforderungen. Umgesetzt von Senior-Entwicklern, maximal zwölf Mandate im Jahr.
Der Unterschied zu allem anderen liegt darin, wer sich anpasst: Bei Standardsoftware passt sich der Betrieb an das Programm an, bei Individualsoftware das Programm an den Betrieb.
Buchhaltung, Zeiterfassung, Warenwirtschaft: Dort ist Eigenentwicklung fast immer die schlechtere Wahl. Interessant wird es bei dem Teil der Abläufe, den kein anderer so hat — meist genau der Teil, der heute über Excel, Mailketten und Zuruf läuft.
Solange Parameter, Felder und Plugins reichen, ist Anpassen der günstigere Weg. Die Grenze liegt dort, wo jedes Hersteller-Update zum Risiko wird. Wenn Mitarbeitende Sonderzeichen in Kommentarfelder schreiben, damit die Auswertung stimmt, ist sie überschritten.
Eine Website zeigt Inhalte. Eine Webanwendung verarbeitet sie: Nutzer mit Rechten, Datenbank, Logik, die rechnet und prüft, Verbindungen zu anderen Systemen. Beides läuft im Browser, im Aufwand liegen Welten dazwischen.
Für die restlichen 20 lohnt fast nie eine Eigenentwicklung. Ausnahme: Diese 20 Prozent sind genau das, womit am Markt Geld verdient wird.
Was intern unklar ist, wird sonst als Unklarheit in Code gegossen. Das wird teuer und niemand nutzt es hinterher.
Entscheidungen, Tests, Einführung brauchen eure Leute. Fehlt diese Zeit, ist Verschieben besser als Starten.
Software ist nie fertig. Wer den Betrieb danach nicht einplant, hat in zwei Jahren ein Problem statt einer Lösung.
Ein zentraler Ablauf läuft über gewachsene Excel-Dateien, die nur eine Person versteht.
Zwei oder mehr Systeme enthalten dieselben Daten, und jemand überträgt sie von Hand.
Zahlen aus mehreren Quellen werden monatlich manuell zusammengestellt.
Ein Ablauf, der euch von Wettbewerbern unterscheidet, lässt sich mit keiner Standardsoftware abbilden.
Ein Altsystem läuft noch, aber niemand kann es mehr warten.
Sofort verfügbar, erprobt, kalkulierbare monatliche Kosten, Hersteller pflegt weiter.
Der Betrieb passt sich an, Lizenzkosten laufen dauerhaft, Anpassungen begrenzt oder teuer.
Volle Kontrolle, Wissen bleibt im Haus, keine externen Tagessätze.
Bindet eigene Entwickler langfristig, bei Personalwechsel steht das System still, Wartung wird selten eingeplant.
Erfahrung aus vielen Projekten, planbare Kapazität, die eigenen Leute bleiben im Kerngeschäft.
Es braucht einen Partner, der bleibt, und Zusagen, die unabhängig halten.
Der häufigste Fehler ist die Mischung ohne Plan: gekauft, intern angepasst, extern erweitert — und nach drei Jahren weiß niemand mehr, wer welchen Teil verantwortet. Wer Wege kombiniert, klärt vorher schriftlich, wem welcher Codeabschnitt gehört und wer ihn wartet.
Niemand muss vorher wissen, welche Software er braucht. Es reicht, das Problem beschreiben zu können. Im Erstgespräch sagen wir, was wir empfehlen würden, welche Technologie dafür in Frage kommt und ob wir dafür die Richtigen sind. Auch wenn die Antwort darauf nein lautet.
Zur Einordnung, ob wir zu einem Vorhaben passen, hier vier Beispiele von Projekten, die wir gebaut haben.
Daten aus mehreren Quellen zusammenführen und so darstellen, dass man damit entscheiden kann. Typischer Auslöser: Die Monatszahlen entstehen bisher in einer Excel-Datei, die eine Person pflegt.
Ein Zugang, über den andere selbst nachsehen können, was sie sonst erfragen müssen. Bestellungen, Dokumente, Status, Verträge.
Anträge, Freigaben, Prüfungen, Planungen. Alles, was heute über Formulare, Mails und Zuruf läuft und niemand nachvollziehen kann.
ERP-Systeme an Branchensoftware anbinden, damit dieselben Daten nicht zweimal erfasst werden müssen. Oft ist das die günstigste Lösung überhaupt: keine neue Software, nur eine Verbindung zwischen zwei vorhandenen.
Bevor überhaupt über Technologie gesprochen wird, klären wir vier Dinge:
Erst danach fällt die Entscheidung. In der Praxis läuft sie oft auf eine dieser drei aus:
Wenn es etwas Passendes gibt, ist das der schnellste und günstigste Weg. Wir sagen das auch dann, wenn wir dabei weniger verdienen.
Wenn die Systeme da sind und nur nicht miteinander reden, bauen wir die Verbindung statt einer neuen Anwendung.
Wenn nichts passt. Dann meist mit Symfony, weil das Framework für datengetriebene Geschäftsanwendungen ausgereift ist, seit Jahren gepflegt wird und viele Entwickler es können. Der letzte Punkt zählt am meisten: Er entscheidet, ob jemand anderes das System übernehmen könnte.
Sechs Datenquellen, eine über Jahre gewachsene Excel-Datei, drei bis vier Arbeitstage pro Monat im Controlling. Zahlen Mitte des Folgemonats, nicht nachvollziehbar — und im Urlaub dieser einen Person gar nicht.
Erst der Test auf Standard-BI: hätte für vier von sechs Quellen gereicht. Gescheitert an zwei firmeneigenen Berechnungsregeln, die im BI-Tool zu unprüfbaren Formeln geworden wären. Also eigene Anwendung, Regeln als lesbarer und testbarer Code. Quellsysteme bleiben führend, nichts wird migriert.
Die Aufbereitung entfällt vollständig. Jede Kennzahl lässt sich bis zum einzelnen Beleg aufklappen, damit Rückfragen im Termin geklärt werden statt in der Woche danach.
Wir haben anfangs nur mit dem Controlling gesprochen. Die Vertriebsleitung kam in Woche acht dazu und brachte Anforderungen mit, die früher billiger gewesen wären. Seitdem holen wir alle Nutzergruppen vor dem ersten Zyklus an den Tisch.
Aufträge in der Branchensoftware, Rechnungen im ERP. Zwei Mitarbeiterinnen übertrugen täglich rund fünfzig Datensätze von Hand. Tippfehler landeten in Rechnungen. Angefragt war eine neue, zusammengeführte Software für beides.
Davon abgeraten. Beide Systeme funktionierten für sich. Das Problem lag in der Lücke dazwischen. Gebaut haben wir eine Schnittstelle: nächtlicher Abgleich für den Bestand, sofortige Übertragung bei Statusänderungen, dazu ein Fehlerprotokoll, das die Fachabteilung selbst einsehen kann.
Die manuelle Übertragung entfällt. Die Zeit steckt jetzt in der Auftragsabwicklung statt in der Doppelerfassung — zu einem Bruchteil dessen, was die angefragte Neuentwicklung gekostet hätte.
Das Fehlerprotokoll war zuerst nur im technischen Log sichtbar. Bis die Fachabteilung selbst hineinsehen konnte, landete jede Unstimmigkeit als Ticket bei uns. Diese Sichtbarkeit bauen wir inzwischen von Anfang an ein.
Ein Pflichtenheft verlangt, am Anfang des Projekts alles zu wissen — zu dem Zeitpunkt, an dem am wenigsten bekannt ist. Was dabei entsteht, ist ein Dokument, das nach drei Monaten nicht mehr stimmt, und ein Änderungsprozess, bei dem jede Korrektur zur Verhandlung wird.
Wir arbeiten stattdessen in kurzen Zyklen. Priorisiert wird gemeinsam: Ihr entscheidet, was als Nächstes wichtig ist, wir sagen, was es kostet. Unsere Projektleitung ist als Professional Scrum Product Owner nach Scrum.org zertifiziert.
Alle zwei Wochen ein lauffähiger Stand, den ihr selbst bedienen könnt. Kein Statusbericht, sondern etwas zum Anfassen. Ab Woche vier ist erkennbar, ob es in die richtige Richtung geht.
Ausstieg jederzeit zum Ende eines Zyklus. Kein Restvolumen, keine Vertragsstrafe.
Kein Lock-in. Der Anbieter lässt sich jederzeit wechseln.
Der Code liegt ab Tag eins in eurem Repository, nicht in unserem.
Festes Budget pro Zyklus. Jeden Monat ist klar, was ausgegeben wurde und was dafür entstanden ist.
Zusammengenommen verschiebt das das Risiko: Statt sich an ein Ergebnis zu binden, das erst in einem Jahr sichtbar wird, fällt die Entscheidung alle zwei Wochen neu.
Zwei Systeme verbinden, klar definierter Datenumfang
Ein Ablauf, ein bis zwei Anbindungen · Produktivbetrieb nach 6 – 10 Wochen
Mehrere Nutzerrollen, Workflows, mehrere Anbindungen · 3 – 6 Monate
Viele Nutzergruppen, umfangreiche Integrationen, hohe Compliance-Anforderungen
Stundensätze für Softwareentwicklung liegen in Deutschland je nach Spezialisierung bei etwa 80 bis 180 €. Stand der Marktangaben: 2026.
Nicht von der Anzahl der Bildschirme: Sonderfälle in den eigenen Regeln, Zahl der Fremdsysteme, Datenqualität in den Quellsystemen. Fünfzig einfache Masken sind günstiger als fünf mit vierzig Preisausnahmen.
Branchenrichtwert, bezogen auf die Entwicklungskosten. Bei 50.000 € sind das 7.500 bis 12.500 € jährlich für Hosting, Sicherheitsupdates, Bibliotheken, geänderte Schnittstellen.
Kein Argument gegen Individualsoftware, sondern gegen die Kaufpreis-Betrachtung: Bei Standardsoftware läuft ebenfalls Geld, dort heißt es Lizenz und steigt mit der Mitarbeiterzahl.
Festpreis funktioniert, wenn der Umfang wirklich feststeht — bei abgegrenzten Schnittstellen, bei größeren Anwendungen fast nie. Sonst passiert eines von zwei Dingen: Risikoaufschlag, den der Kunde mitbezahlt, oder Sparen an Qualität, das später auffällt. Wir rechnen nach Aufwand mit festem Budgetrahmen pro Zyklus.
Meistens gibt es ein ERP, eine Warenwirtschaft, ein CRM, manchmal einen Shop — und die neue Anwendung muss sich einfügen.
Im besten Fall hat das Zielsystem eine dokumentierte Schnittstelle, dann bauen wir dagegen. Wenn nicht, gibt es Wege über Datenbankzugriff, Dateiaustausch oder eine Zwischenschicht. Was möglich ist, klären wir vor dem Angebot, nicht danach.
Übernommen wird, was gebraucht wird. Der Aufwand steckt fast nie im Kopieren, sondern im Bereinigen: doppelte Datensätze, uneinheitliche Schreibweisen, Felder, die über Jahre zweckentfremdet wurden.
Wenn ein Altsystem stört, ist die Ablösung nicht automatisch die Antwort. Oft reicht es, das Altsystem laufen zu lassen und eine neue Oberfläche davorzusetzen. Für eine Ablösung sprechen andere Gründe: fehlende Sicherheitsupdates, kein Support mehr, oder niemand, der das System noch versteht.
Ohne feste Priorisierung wird alles gebaut, und am Ende ist das Geld weg, bevor der Kern fertig ist. Gegenmittel: Jeder Zyklus hat ein festes Budget, und was neu dazukommt, verdrängt etwas anderes. Diese Entscheidung trefft ihr, nicht wir.
Wenn fünf Abteilungen mitreden und niemand entscheidet, entstehen Kompromisse, die keiner will. Es braucht auf Kundenseite eine Person, die im Zweifel sagt, was gilt.
Software, die an den tatsächlichen Abläufen vorbeigeht, wird umgangen. Deshalb sprechen wir mit den Leuten, die damit arbeiten sollen, nicht nur mit denen, die das Projekt beauftragen.
Kein Budget für Betrieb, keine Zuständigkeit, keine Updates. Nach zwei Jahren läuft die Anwendung auf veralteten Bibliotheken und niemand traut sich, etwas anzufassen. Das ist der häufigste stille Tod.
Wenn Code undokumentiert ist, auf exotischen Technologien läuft oder in einem fremden Repository liegt, wird jeder Wechsel zum Neubau. Was dagegen hilft, steht im nächsten Abschnitt.
Quellcode in eurem Repository, ab dem ersten Tag.
Uneingeschränkte und ausschließliche Nutzungsrechte bei euch, inklusive Bearbeitung durch Dritte.
Verbreitete Technologien mit Arbeitsmarkt. Kein Eigenframework.
Setup, Deployment und Architektur dokumentiert für den Fall, dass wir nicht mehr dabei sind.
Ausstieg jederzeit zum Ende eines Zyklus, Anbieterwechsel inklusive.
Wir empfehlen jedem Kunden, das Hosting selbst zu beauftragen — auf den eigenen Namen, mit den eigenen Zugangsdaten. Keine festen Partnerschaften, keine Provisionen. Serverstandort in der EU ist für uns gesetzt.
Nein, aber sie verändert, wie schnell und wie günstig entwickelt wird. Deshalb entscheiden wir pro Projekt, ob und wie stark wir KI einsetzen, und besprechen das vorher.
Die richtige Wahl bei sensiblen Daten, hohen Datenschutzanforderungen und sicherheitskritischen Anwendungen. Überall dort, wo Code oder Daten das Haus nicht verlassen dürfen.
Schnelles Prototyping, zügige Integrationen, kürzere Wege bis zum ersten lauffähigen Stand. Früher erkennbar, ob eine Idee trägt, und früher umsteuerbar.
In der Praxis ist der zweite Weg heute der häufigere. Was sich dabei nicht ändert: Jede Zeile geht durch einen Senior-Entwickler, der sie prüft und hinterfragt. KI erzeugt Code, der plausibel aussieht und trotzdem falsch sein kann, besonders bei Rechteprüfung, Berechnungen und Randfällen. Die Ersparnis geben wir weiter, indem früher etwas Lauffähiges dasteht. Nicht, indem wir die Prüfung weglassen.
klar abgegrenzte Aufgabe, kleines Budget
Ausfall, Urlaub, Nachfolge — es gibt nur eine Person
mittlere Projekte, Beratung und Umsetzung aus einer Hand
Team wechselt mitten im Projekt, Junior-Besetzung nach dem Verkaufsgespräch
große, langlaufende Systeme mit vielen Beteiligten
Overhead, langsame Entscheidungen, hohe Mindestvolumen
Budgetdruck, klar spezifizierte Aufgaben
Abstimmungsaufwand, Zeitzonen, Sprache bei fachlichen Details
Die vierte Frage ist die aussagekräftigste. Wer noch nie abgelehnt hat, verkauft alles.
Namentlich benannte Personen mit Rolle. Ein Vorgehen mit Zyklen und Terminen. Eine Aussage zu Quellcode und Rechten. Betriebskosten getrennt von Entwicklungskosten. Und eine Liste dessen, was ausdrücklich nicht enthalten ist — die fehlt fast immer und verursacht später den meisten Ärger.
Der erste lauffähige Stand steht nach wenigen Wochen. Bis zum produktiven Einsatz vergehen bei klar abgegrenztem Umfang marktüblich 6 bis 10 Wochen, bei ausgebauten Anwendungen mit mehreren Rollen und Anbindungen 3 bis 6 Monate. Größere Plattformen wachsen über Jahre, gehen aber schon vorher in Betrieb.
Unterhalb von etwa 5.000 Euro ist der Aufwand für Abstimmung und Einarbeitung im Verhältnis zu hoch. In diesem Bereich fährt man mit einer Standardlösung oder einem Automatisierungswerkzeug fast immer besser. Das sagen wir im Erstgespräch, statt ein zu kleines Projekt zu verkaufen.
Ein bis zwei Stunden pro Woche für Abstimmung und Rückmeldung, dazu Testzeit vor jedem größeren Schritt. Die Datenübernahme aus Altsystemen ist der Teil, der auf Kundenseite am meisten Zeit kostet.
Ja, wenn Quellcode und Zugänge vorhanden sind. Wir sehen uns den Stand vorher an und sagen, ob Übernahme oder Neubau der bessere Weg ist. Diese Einschätzung ist Teil des Erstgesprächs.
Auf Servern innerhalb der EU. Das Hosting beauftragt ihr selbst, auf euren Namen — wir beraten bei der Auswahl, verdienen daran aber nichts und arbeiten mit keinem Anbieter exklusiv zusammen.
Es reicht, das Problem beschreiben zu können. Zurück kommt eine Einschätzung, was wir empfehlen würden, welche Technologie in Frage kommt und ob wir dafür die Richtigen sind. Auch wenn die Antwort nein lautet.
3-Einträge
3-Einträge
4-Einträge
5-Einträge
2-Einträge
4-Einträge
Sie sehen gerade einen Platzhalterinhalt von Vimeo. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr Informationen
