Beratung für Software Engineering und Architektur
Softwareentwicklung und Architektur: Systeme, die die nächste Änderung überleben
Softwareentwicklungsberatung ordnet die Frage, wie ein Haus zu seiner eigenen Software kommt und wie es sie über Jahre änderungsfähig hält: welcher Teil der Fachlogik überhaupt eigenentwickelt gehört, wie das System entlang der Fachlichkeit geschnitten wird, welche Schnittstellen nach außen tragen und woran ablesbar ist, dass Qualität nicht nur behauptet wird. Wichtig wird das Thema, sobald eine Anwendung ihren Zweck erfüllt, aber jede weitere Erweiterung länger dauert als die vorige — oder sobald ein Altsystem nur noch von zwei, drei Personen wirklich verstanden wird. Nötig sind dafür zwei Dinge, die selten gleichzeitig im Haus liegen: Entwurfserfahrung über mehrere Systemgenerationen und die Bereitschaft, den fachlichen Schnitt vor der Technologiewahl zu klären.
Führende Unternehmen vertrauen auf unser Netzwerk
Was Softwareentwicklungsberatung leistet — und was nicht

Softwareentwicklungsberatung — je nach Haus auch Software-Architekturberatung, Beratung für Individualsoftware oder Software-Engineering-Beratung genannt — bewertet ein System nicht danach, ob es fertig ist. Fertig ist Software nie. Bewertet wird, was die nächste Änderung kostet: an Tagen, an Abstimmung, an Risiko im Betrieb. Diese eine Zahl entscheidet darüber, ob ein Haus in fünf Jahren noch handlungsfähig ist, und sie steht in keinem Abnahmeprotokoll.
Lauffähig ist nicht änderbar. Zwei Anwendungen können dieselbe Fachaufgabe gleich gut erledigen und sich in den Folgekosten um den Faktor fünf unterscheiden. Der Unterschied steckt nicht im Funktionsumfang, sondern in den Abhängigkeiten: wie viele Stellen eine neue Anforderung berührt, wie oft eine Änderung an einer Stelle etwas an einer anderen zerlegt, wie lange es dauert, bis jemand mit Gewissheit sagen kann, dass nichts kaputt ist. Wer nur die Funktion abnimmt, kauft die Änderungskosten unbesehen mit.
Der Schnitt entscheidet vor der Technologie. Die Frage, welches Framework, welche Datenbank, welcher Cloud-Dienst, wird meist zuerst gestellt und ist die unwichtigere. Wichtiger ist, wo die Grenzen zwischen den fachlichen Bereichen liegen und welcher Bereich welche Daten besitzt. Ein Schnitt quer zur Fachlichkeit lässt sich später nicht durch Technologie reparieren; ein guter Schnitt erlaubt es dagegen, Technologien einzeln zu tauschen, ohne das Ganze anzufassen.
Wissen im Kopf ist nicht Wissen im System. Wo Regeln nur als Erfahrung einzelner Personen existieren, ist jede Abwesenheit ein Betriebsrisiko und jede Einarbeitung ein Monat. Änderungsfähigkeit heißt deshalb auch: automatisierte Tests, die eine Aussage treffen, eine reproduzierbare Auslieferung und eine Dokumentation der Entscheidungen — nicht der Zeilen. Diese drei Dinge sind das, was ein Team nach dem Weggang eines Schlüsselentwicklers noch hat.
Im englischsprachigen Umfeld heißen dieselben Aufgaben software engineering consulting, software architecture consulting oder custom software development consulting; wer nach software architects oder senior software engineers sucht, meint in der Regel diese Leistung. Für international besetzte Entwicklungsteams arbeiten wir zweisprachig.
Was sie nicht leistet. Sie nimmt Ihnen die Produktentscheidung nicht ab: was gebaut wird, welche Anforderung Vorrang hat und was ein Feature wert ist, bleibt im Haus. Und sie kann eine Fachlichkeit nicht klären, die niemand entscheiden will — wo zwei Bereiche sich über die Definition eines Kunden, eines Auftrags oder eines Preises nicht einigen, entsteht kein Systemschnitt, sondern eine Schnittstelle mehr.
Wo diese Seite endet: IT-Strategie, Applikationslandschaft, Sourcing und Betriebsführung behandeln wir in der IT-Beratung. Plattform, Migration und Kostensteuerung stehen in der Cloud-Beratung, Datenmodelle und Berichtswesen in der Business-Intelligence-Beratung. Für Modelle und deren Einbettung ins Produkt siehe die KI-Beratung, für Arbeitsweise und Zusammenarbeit im Team die Agile Transformation.
Wann externe Unterstützung in einem Softwarevorhaben weiterhilft
Ein eingespieltes Entwicklungsteam mit klarem Auftrag braucht keine Beratung. Der Bedarf entsteht an den Stellen, an denen ein Team seine eigene Lage nicht mehr von innen beurteilen kann — weil die Entscheidung größer ist als der nächste Sprint, weil das nötige Wissen im Haus nie aufgebaut wurde, oder weil eine Aussage gebraucht wird, die nicht von denen kommt, die das System gebaut haben.
1. Jede Erweiterung dauert länger als die vorige
- Die Anwendung tut, was sie soll, aber der Aufwand für vergleichbare Änderungen steigt von Quartal zu Quartal.
- Niemand kann benennen, woran das liegt — die Vermutungen im Team gehen auseinander.
- Gesucht ist eine Bestandsaufnahme, die die Ursachen nach Wirkung sortiert, statt eine Neuentwicklung zu empfehlen.
2. Ein Altsystem hängt an einzelnen Personen
- Zwei oder drei Personen verstehen die Fachlogik, geschrieben ist sie nirgends.
- Der Hersteller einer eingesetzten Komponente hat den Support beendet oder die Laufzeitumgebung ist abgekündigt.
- Gesucht ist ein Weg, das Wissen ins System zu holen, bevor es das Haus verlässt.
3. Vor der Entscheidung fehlt eine unabhängige Aussage
- Ein Anbieter oder das eigene Team schlägt einen Entwurf vor, im Haus fehlt der Maßstab, ihn zu prüfen.
- Kaufen oder bauen ist ungeklärt, und beide Lager argumentieren mit Zahlen, die niemand nachrechnen kann.
- Gesucht ist eine Zweitmeinung mit Begründung, nicht eine Empfehlung mit Angebot dahinter.
4. Das Vorhaben ist beschlossen, die Kapazität fehlt
- Budget und Zieltermin stehen, die passenden Profile sind am Markt nicht kurzfristig festanstellbar.
- Das bestehende Team trägt parallel den Betrieb und kann nicht beides.
- Gesucht ist Verstärkung, die sich in die vorhandene Arbeitsweise einfügt, statt eine zweite daneben aufzubauen.
5. Die Schnittstellen sind der Engpass, nicht die Anwendung
- Neue Anbindungen an ERP, Shop, Portal oder Partner dauern jedes Mal von neuem Monate.
- Dieselben Daten liegen in mehreren Systemen unterschiedlich, und keiner ist als führend festgelegt.
- Gesucht ist eine tragfähige Ordnung der Schnittstellen, nicht die nächste Punkt-zu-Punkt-Verbindung.
6. Nach einem Zwischenfall fehlt Vertrauen in die Auslieferung
- Ein Release hat den Betrieb gestört, seither wird seltener und mit mehr Aufwand ausgeliefert.
- Tests gibt es, aber ihre grüne Farbe sagt nichts über den Zustand des Systems.
- Gesucht ist ein Prüfnetz, das eine belastbare Aussage trifft — und damit häufigere, kleinere Auslieferungen erlaubt.
Kommt Ihnen einer dieser Auslöser bekannt vor? Zwanzig Minuten reichen, um Ihre Lage einzuordnen und zu sagen, ob eine Bestandsaufnahme, ein Entwurf oder zusätzliche Entwicklungskapazität der richtige nächste Schritt ist.
Wo Softwareentwicklungsberatung ansetzt: die Ebenen vom Code bis zur Systemlandschaft
Softwarearbeit lässt sich auf sechs Ebenen beschreiben, die aufeinander aufbauen und einzeln oder in Kombination besetzbar sind. Ein Vorhaben scheitert selten an der Ebene, an der es gerade arbeitet — es scheitert an der darunter, die übersprungen wurde. Deshalb ist die erste Frage nie, wie gebaut wird, sondern auf welcher Ebene die Unklarheit sitzt.
Anforderungen und fachlicher Schnitt
Bevor eine Zeile entsteht, wird die Fachlichkeit sortiert: Welche Begriffe bedeuten in welchem Bereich was, wer besitzt welche Daten, welche Regeln sind Gesetz und welche sind gewachsene Gewohnheit. Aus dieser Sortierung entstehen die Grenzen des späteren Systems. Ergebnis ist ein abgestimmtes Begriffsmodell und eine Liste der Stellen, an denen zwei Bereiche dasselbe Wort verschieden verwenden — die häufigste Quelle späterer Sonderfälle.
Architektur und Zielbild
Das Zielbild legt fest, aus welchen Bausteinen das System besteht, welcher Baustein welche Verantwortung trägt und wie sie miteinander sprechen. Dazu gehört die ehrliche Begründung der Zuschnitthöhe: ein Monolith mit klaren inneren Grenzen ist für viele Häuser die tragfähigere Antwort als verteilte Dienste, die eine Betriebsmannschaft voraussetzen, die es nicht gibt. Festgehalten werden nicht Diagramme, sondern Entscheidungen samt Alternativen und Grund.
Umsetzung und Entwicklungskapazität
Auf dieser Ebene wird gebaut: Fachanwendungen, Backend-Dienste, Weboberflächen, Auswertungslogik, Automatisierungen. Externe Kapazität arbeitet dabei in der Arbeitsweise des Hauses und nicht daneben — gleiche Repositories, gleiche Prüfschritte, gleiche Auslieferungswege. Wo eine Technologie im Haus neu ist, gehört das Anlernen der eigenen Leute zum Auftrag, nicht in eine Anschlussphase.
Schnittstellen und Integration
Kaum eine Anwendung steht allein. Hier wird geklärt, welches System für welchen Datensatz führend ist, welche Schnittstellen synchron antworten müssen und welche besser ereignisgesteuert arbeiten, und wie Versionswechsel möglich bleiben, ohne alle Anbindungen gleichzeitig anzufassen. Verträge über Schnittstellen werden explizit gemacht und geprüft — nicht aus Formalismus, sondern weil sie die Stelle sind, an der Änderungen sonst am teuersten werden.
Qualität, Test und Sicherheit
Ein Prüfnetz ist nur dann eines, wenn ein roter Lauf eine echte Aussage bedeutet. Dazu gehören Tests auf der richtigen Ebene statt möglichst vieler, Prüfungen der Abhängigkeiten und ihrer Lizenzen, das Erkennen bekannter Schwachstellen im Bauprozess und die Frage, wie Fehler im Betrieb sichtbar werden, bevor Anwender sie melden. Sicherheit im Anwendungscode gehört hierher; das organisatorische Schutzniveau steht in der Cyber-Security-Beratung.
Betrieb, Übergabe und Weiterentwicklung
Eine Anwendung ist ab dem ersten Tag im Betrieb ein Dauerposten. Auf dieser Ebene geht es um reproduzierbare Auslieferung, um Beobachtbarkeit im laufenden System und um die Frage, wer die Anwendung nach dem Ende des externen Mandats tatsächlich weiterentwickelt. Eine Übergabe, die aus einer Dokumentation besteht, ist keine — übergeben ist, was das eigene Team ohne Rückfrage geändert hat.
Welche Ebene bei Ihnen den Ausschlag gibt, lässt sich in einem kurzen Gespräch einordnen — meist genügen die Historie der letzten drei Releases und ein Blick auf die Abhängigkeiten.
Wie externe Entwicklungskapazität eingebunden wird
In Softwarevorhaben entscheidet neben der Fachtiefe vor allem, wo die Entscheidungshoheit liegt. Wer einen Entwurf verantwortet, braucht andere Befugnisse als wer eine Anforderung umsetzt, und beide brauchen etwas anderes als jemand, der eine bestehende Architektur prüfen soll. Vier Zuschnitte deckt unser Netzwerk regelmäßig ab; sie unterscheiden sich in Entscheidungsspielraum und Einbindungstiefe, nicht im Anspruch.
Zielbild für ein neues System
Eine Architektin oder ein Architekt klärt Fachschnitt, Bausteine und Schnittstellen und hinterlässt begründete Entscheidungen samt Alternativen. Die Umsetzung übernimmt danach das eigene Team oder ein Dienstleister — der Entwurf ist absichtlich so geschrieben, dass beides möglich bleibt.
Verstärkung im bestehenden Team
Senior-Entwicklerinnen und -Entwickler arbeiten in Ihren Repositories, Ihren Prüfschritten und Ihrem Rhythmus mit. Die fachliche Priorisierung bleibt bei Ihnen; mitgebracht wird Erfahrung mit vergleichbaren Systemen und die Bereitschaft, das eigene Wissen im Team zu verankern.
Technische Führung auf Zeit
Eine Person übernimmt die technische Verantwortung für eine Anwendung oder ein Team — bei Vakanz, während eines Aufbaus oder wenn eine strittige Architekturentscheidung eine Instanz braucht, die sie trifft und trägt.
Zweitmeinung zu einer Architektur
Ein eng gefasster Auftrag mit Berichtsergebnis: bestehende Architektur, Angebot eines Dienstleisters oder Bau-oder-Kauf-Frage werden geprüft und die Befunde nach Wirkung auf die Änderungskosten sortiert — ohne Anschlussangebot im Rücken.
Softwareentwicklung nach Branche: was die Domäne dem Entwurf vorschreibt
Software lässt sich nicht branchenneutral entwerfen, weil die Fachlichkeit die Grenzen des Systems bestimmt und nicht die Technologie. Was in einem Handelsunternehmen ein Auftrag ist, ist in der Versicherung ein Vertrag mit Historie und im Maschinenbau eine Konfiguration mit Stückliste — und diese Unterschiede schlagen bis in den Datenschnitt durch. Ebenso unterschiedlich ist der Rahmen: Wo eine Anwendung in einer Anlage läuft, entscheidet die Betriebssicherheit über die Auslieferungsfrequenz; wo Aufsichtsrecht gilt, ist Nachvollziehbarkeit eine Anforderung an die Architektur und keine Dokumentationsaufgabe; wo Lastspitzen saisonal auftreten, wird der Schnitt entlang der Skalierung gezogen.
Wir besetzen deshalb nach Domänenerfahrung, nicht nur nach Sprache und Framework: Eine Entwicklerin, die Chargenrückverfolgung schon dreimal gebaut hat, stellt am ersten Tag die Fragen, auf die ein fachfremdes Team im dritten Monat stößt. Die folgenden Felder sind der Ausschnitt, in dem wir am häufigsten besetzen — weitere Domänen erschließen wir über das Netzwerk.
Industrie & Maschinenbau
Produktkonfiguration, Stücklisten und Rückverfolgbarkeit erzeugen Datenmodelle mit vielen Varianten und langen Lebenszyklen: Eine Maschine, die heute ausgeliefert wird, muss in fünfzehn Jahren noch in derselben Anwendung auffindbar sein. Dazu kommt die Nähe zur Anlage — Software, die in der Fertigung mitläuft, wird nicht mehrfach täglich ausgeliefert, sondern in Fenstern. Der Entwurf muss beides aushalten: langlebige Daten und seltene, dafür sichere Auslieferung.
Banken & Versicherungen
Aufsichtsrecht macht Nachvollziehbarkeit zur Architekturanforderung: Jede Zustandsänderung muss rekonstruierbar sein, Berechnungen müssen zum Stichtagsstand nachrechenbar bleiben, Auslagerung an Dritte ist zu belegen. Das verändert den Entwurf — Ereignisse werden nicht überschrieben, sondern fortgeschrieben. Bestandsanwendungen sind hier oft älter als die Teams, die sie betreuen, weshalb Ablösung fast immer schrittweise und im Parallelbetrieb erfolgt.
Handel & E-Commerce
Sortiment, Preis und Verfügbarkeit ändern sich schneller als jede Auslieferung, deshalb gehören sie in Daten und nicht in Code. Der eigentliche Entwurfsdruck kommt aus der Saisonalität: Ein System muss an wenigen Tagen im Jahr ein Vielfaches der Normallast tragen, ohne dass sich diese Reserve das ganze Jahr bezahlt. Zusätzlich sind Kanäle zu vereinheitlichen — dieselbe Bestellung erreicht das Haus über Shop, Marktplatz, Filiale und Telefon.
Software & SaaS
Wer Software als Produkt verkauft, trägt viele Kundenstände gleichzeitig: Mandantentrennung, Konfigurierbarkeit ohne Codeverzweigung und ein Versionsversprechen an Schnittstellen. Die teuerste Altlast entsteht hier durch kundenspezifische Sonderwege, die einmal schnell gingen und jede weitere Änderung verdoppeln. Der Entwurf muss Varianz erlauben, ohne sie im Code abzubilden.
Energie & Versorger
Marktprozesse sind vorgegeben und ändern sich mit der Regulierung, nicht mit dem Produktplan: Formate, Fristen und Rollen im Marktverkehr sind gesetzt, das eigene System muss ihnen folgen. Dazu kommen Zeitreihen in großer Menge und feiner Auflösung, die ein anderes Datenmodell verlangen als klassische Geschäftsobjekte. Änderbarkeit heißt hier vor allem: Regeländerungen einbauen können, ohne die Abrechnung anzuhalten.
Automotive & Embedded
Software auf einem Gerät kann nicht zurückgerollt werden wie ein Serverdienst, und Ressourcen sind fest: Speicher, Rechenzeit und Energie begrenzen den Entwurf von vornherein. Freigabeprozesse und Nachweispflichten verlängern jeden Zyklus, weshalb Fehler früh gefunden werden müssen — auf dem Prüfstand und nicht im Feld. Der Übergang zwischen Gerätesoftware und angebundenem Dienst ist die Stelle, an der die Verantwortung am häufigsten unklar ist.
Industrie & Maschinenbau
Produktkonfiguration, Stücklisten und Rückverfolgbarkeit erzeugen Datenmodelle mit vielen Varianten und langen Lebenszyklen: Eine Maschine, die heute ausgeliefert wird, muss in fünfzehn Jahren noch in derselben Anwendung auffindbar sein. Dazu kommt die Nähe zur Anlage — Software, die in der Fertigung mitläuft, wird nicht mehrfach täglich ausgeliefert, sondern in Fenstern. Der Entwurf muss beides aushalten: langlebige Daten und seltene, dafür sichere Auslieferung.
Banken & Versicherungen
Aufsichtsrecht macht Nachvollziehbarkeit zur Architekturanforderung: Jede Zustandsänderung muss rekonstruierbar sein, Berechnungen müssen zum Stichtagsstand nachrechenbar bleiben, Auslagerung an Dritte ist zu belegen. Das verändert den Entwurf — Ereignisse werden nicht überschrieben, sondern fortgeschrieben. Bestandsanwendungen sind hier oft älter als die Teams, die sie betreuen, weshalb Ablösung fast immer schrittweise und im Parallelbetrieb erfolgt.
Handel & E-Commerce
Sortiment, Preis und Verfügbarkeit ändern sich schneller als jede Auslieferung, deshalb gehören sie in Daten und nicht in Code. Der eigentliche Entwurfsdruck kommt aus der Saisonalität: Ein System muss an wenigen Tagen im Jahr ein Vielfaches der Normallast tragen, ohne dass sich diese Reserve das ganze Jahr bezahlt. Zusätzlich sind Kanäle zu vereinheitlichen — dieselbe Bestellung erreicht das Haus über Shop, Marktplatz, Filiale und Telefon.
Software & SaaS
Wer Software als Produkt verkauft, trägt viele Kundenstände gleichzeitig: Mandantentrennung, Konfigurierbarkeit ohne Codeverzweigung und ein Versionsversprechen an Schnittstellen. Die teuerste Altlast entsteht hier durch kundenspezifische Sonderwege, die einmal schnell gingen und jede weitere Änderung verdoppeln. Der Entwurf muss Varianz erlauben, ohne sie im Code abzubilden.
Energie & Versorger
Marktprozesse sind vorgegeben und ändern sich mit der Regulierung, nicht mit dem Produktplan: Formate, Fristen und Rollen im Marktverkehr sind gesetzt, das eigene System muss ihnen folgen. Dazu kommen Zeitreihen in großer Menge und feiner Auflösung, die ein anderes Datenmodell verlangen als klassische Geschäftsobjekte. Änderbarkeit heißt hier vor allem: Regeländerungen einbauen können, ohne die Abrechnung anzuhalten.
Automotive & Embedded
Software auf einem Gerät kann nicht zurückgerollt werden wie ein Serverdienst, und Ressourcen sind fest: Speicher, Rechenzeit und Energie begrenzen den Entwurf von vornherein. Freigabeprozesse und Nachweispflichten verlängern jeden Zyklus, weshalb Fehler früh gefunden werden müssen — auf dem Prüfstand und nicht im Feld. Der Übergang zwischen Gerätesoftware und angebundenem Dienst ist die Stelle, an der die Verantwortung am häufigsten unklar ist.
Auftragsbilder in Softwarevorhaben und ihr Prüfstein
Was in der Softwareentwicklung beauftragt wird, fällt zum größten Teil in wenige wiederkehrende Bilder. Für jedes gibt es einen Prüfstein — die Größe, an der sich nach Abschluss zeigt, ob der Auftrag etwas verändert hat. Ohne diesen Prüfstein endet ein Vorhaben mit einer Lieferung statt mit einem Ergebnis.
Neuentwicklung einer Fachanwendung
Ausgangslage: Ein Prozess läuft über Tabellen und Zurufe, eine Standardlösung passt nicht auf die Besonderheit, die das Geschäft ausmacht. Gebaut wird zuerst der Kern, der diese Besonderheit trägt, alles Übrige wird zugekauft oder angebunden. Prüfstein: die Durchlaufzeit des unterstützten Prozesses und der Anteil manueller Nacharbeit — nicht die Zahl umgesetzter Anforderungen.
Ablösung eines Altsystems
Ausgangslage: Eine tragende Anwendung ist technisch am Ende, fachlich aber unverzichtbar und nirgends vollständig beschrieben. Abgelöst wird in Abschnitten mit Parallelbetrieb, beginnend an der Stelle mit dem geringsten Rückweg. Prüfstein: der Anteil des Altsystems, der nachweislich abgeschaltet ist — ein zu 90 Prozent ersetztes System kostet so viel wie ein ganzes.
Architektur-Review vor der Entscheidung
Ausgangslage: Ein Entwurf liegt vor — aus dem eigenen Haus oder von einem Anbieter — und es fehlt eine unabhängige Einschätzung, bevor Budget gebunden wird. Geprüft werden Fachschnitt, Abhängigkeiten, Betriebsannahmen und die Frage, was der Entwurf im Fall einer Kehrtwende kostet. Prüfstein: benannte Risiken mit Eintrittsbedingung und eine Aussage zur Umkehrbarkeit jeder tragenden Festlegung.
Verstärkung für ein laufendes Vorhaben
Ausgangslage: Der Zieltermin steht, das Team trägt parallel den Betrieb, und die gesuchten Profile sind nicht kurzfristig festanstellbar. Ergänzt wird innerhalb der bestehenden Arbeitsweise, nicht als zweites Team daneben. Prüfstein: die Auslieferungsfrequenz nach dem Zugang — steigt sie nicht innerhalb weniger Wochen, war nicht Kapazität der Engpass.
Rollen, die ein Softwarevorhaben tragen
Wie aus einem Architekturentwurf lauffähige Software wird
Umfang und Reihenfolge der Abschnitte hängen davon ab, wie viel Fachlogik im Spiel ist, wie viele Systeme angebunden sind und wie viel Rückweg jede Festlegung lassen muss. Die Folge selbst ist stabil: Was übersprungen wird, kommt später als Sonderfall zurück.
1. Bestandsaufnahme statt Vermutung
2. Fachlicher Schnitt und Zielbild
3. Referenzimplementierung eines Ausschnitts
4. Prüfnetz mit Aussagekraft
5. Schrittweise Ersetzung im Parallelbetrieb
6. Übergabe und Weiterentwicklung im Haus
Was Softwareentwicklung mit externen Fachleuten kostet
Externe Unterstützung in Entwicklung und Architektur wird bei uns nach Tagessatz abgerechnet, nicht nach Projektpauschale. Der Satz ergibt sich aus fünf Größen: der Entwurfsverantwortung im Auftrag (Architekturrollen liegen über reinen Umsetzungsrollen), der Seltenheit des Technologieprofils, der Domäne und ihrem Nachweisbedarf, dem Präsenzanteil vor Ort sowie der Mandatsdauer — längere Mandate liegen pro Tag niedriger.
Die Spannen unseres Bestands im Fachbereich Software Engineering & Architektur liegen aktuell zwischen 450 € und 1.200 € pro Tag. Je Rolle ausgewiesen sieht das so aus:
-
Freelance Full Stack Developer
900 – 1.200 € pro Tag
-
Freelance Backend Developer (Java / Python / Go)
750 – 1.200 € pro Tag
-
750 – 900 € pro Tag
-
Freelance Legacy-Modernisierung Consultant
750 – 900 € pro Tag
-
750 – 900 € pro Tag
-
700 – 850 € pro Tag
-
Freelance Embedded Software Entwickler
600 – 800 € pro Tag
-
Freelance Headless CMS Frontend Entwickler
650 – 750 € pro Tag
-
600 – 750 € pro Tag
-
500 – 750 € pro Tag
-
550 – 700 € pro Tag
-
Freelance E-Commerce Frontend Entwickler
570 – 650 € pro Tag
-
Freelance Mobile Testing Engineer
450 – 600 € pro Tag
Jede Spanne ist auf der jeweiligen Rollenseite ausgewiesen — nicht auf Anfrage.
Wie sich ein Vorhaben budgetieren lässt. Gerechnet wird in Personentagen, nicht in einer Gesamtsumme. Eine Bestandsaufnahme mit Abhängigkeits- und Änderungsanalyse liegt für eine mittelgroße Anwendung meist bei 10 bis 20 Personentagen. Ein Zielbild samt Referenzausschnitt eher bei 30 bis 60 Tagen. Eine Ablösung wird in Abschnitten gerechnet, damit nach jedem Abschnitt entscheidbar ist, ob der nächste den Aufwand rechtfertigt. Verstärkung im laufenden Team rechnet anders: drei bis fünf Tage pro Woche über sechs bis achtzehn Monate.
Der aussagekräftigere Vergleich ist nicht der Tagessatz, sondern der Aufwand der Änderung, die Sie sich damit erkaufen: Wenn eine typische Erweiterung heute vierzig Personentage kostet und nach dem Entwurf zwölf, ist ein Zielbild über dreißig Tage nach zwei Erweiterungen eingespielt. Wo eine Anwendung ohnehin nur noch einmal im Jahr angefasst wird, lohnt kein Umbau — diese Antwort geben wir vor dem Angebot.
Was ein Netzwerk anders abrechnet als ein Lieferwerk. Bezahlt wird die Person, die entwirft oder entwickelt, und keine Struktur über ihr: kein Engagement Manager, kein Partneranteil, keine Sockelkosten für Methodik. Dafür bekommen Sie kein Lieferwerk — Sie beauftragen einzelne Fachleute oder ein kleines Team und behalten die Produktverantwortung im Haus. Festpreise auf Basis eines Lastenhefts bilden wir nicht ab: sie setzen den Anreiz, den Umfang zu verteidigen, statt die Lösung zu verbessern.
Welches Profil trägt, entscheidet die Ebene der Unklarheit: Ein Zielbild verlangt andere Erfahrung als die Ablösung eines gewachsenen Altsystems. Die vollständige Übersicht steht unter Software Engineering & Architektur — darunter Software Architekt, API Architekt, Full Stack Developer, Backend Developer und Mobile Testing Engineer. Für angrenzende Aufgaben ergänzen Cloud, Infrastruktur & DevOps, Data Engineering & Data Science, Product Management & UX und Cybersecurity.
Offene IT-Stellen bleiben im Schnitt über ein halbes Jahr unbesetzt
109.000
7,7 Monate
12 %
Wiederkehrende Fragen zu externer Softwareentwicklung
Ausgezeichnet. Finden nicht nur wir selbst.
consultingheads wurde mehrfach von führenden Fachmagazinen und unabhängigen Dritten ausgezeichnet.