Komplette Projekte vom Backend über das Frontend bis zur Dev-Umgebung — saubere Fundamente, echte Produktionstauglichkeit, ein Verantwortlicher.
Sie suchen nicht nur einen Entwickler für ein Modul, sondern jemanden, der ein vollständiges Software-Projekt übernehmen oder mitgestalten kann — Backend, Frontend, Datenbank, CI/CD, Monitoring. Ohne Lieferanten-Patchwork, ohne dass Sie selbst zum Projekt-Koordinator zwischen drei Dienstleistern werden. Mit sauberen Fundamenten von Anfang an, damit das System auch in zwei Jahren noch trägt — und mit einer Time-to-Market, die nicht nur in der Demo schnell aussieht, sondern auch unter Last hält.
Warum so viele Software-Projekte enttäuschen
Der typische Verlauf: Sie beschreiben einen Bedarf. Der Lieferant zeigt einen schicken Prototyp — oft schon mit AI-Buzzwords angereichert. Sie sehen Fortschritt, der Vertrag wird gemacht, das Projekt startet. Sechs Monate später haben Sie ein System, das beeindruckend aussieht und alle modernen Patterns abhakt — aber drei zentrale Schritte Ihres tatsächlichen Workflows lässt es links liegen, weil sie in der Discovery-Phase niemand vollständig verstanden hat. Oder Sie haben ein System, das im Demo lief und in der Produktion bei der zehnten parallelen Anfrage zusammenbricht, weil 'Produktionstauglichkeit' im Sprint-Backlog immer ans Ende rutschte.
Die Demo-Wow-Falle
AI-generierte Prototypen sehen in der Präsentation fertig aus — und brechen unter echten Daten, echter Last und echten Edge-Cases zusammen.
Das ist kein Einzelfall, sondern Mechanik der Branche: Geschwindigkeit zum Demo-Zeitpunkt wird belohnt, Tiefe der Analyse selten honoriert, saubere Fundamente fast nie sichtbar verkauft. Mit moderner AI-Toolchain lässt sich heute in Tagen ein Prototyp generieren, der wie ein fertiges Produkt aussieht. Time-to-Market klingt damit eindrucksvoll — bis Sie feststellen, dass der Prototyp Ihren tatsächlichen Use-Case nicht trifft, keine Last verträgt und niemand wirklich verantwortlich ist, wenn er nicht trägt.
Hinzu kommt: viele Anbieter liefern nur Teilstücke. Das Backend kommt von einem, das Frontend von einem zweiten, DevOps und Monitoring werden 'später' geklärt — und Sie sitzen plötzlich in der Rolle eines Projekt-Koordinators, für die Sie kein Spezialist sind. Genau dort entstehen die Architektur-Brüche, die ein System Jahre kosten.
Das Patchwork-Problem
Backend von Anbieter A, Frontend von B, DevOps 'irgendwann' — und Sie werden zum Koordinator zwischen Lieferanten, statt jemanden zu haben, der alles verantwortet.
Mein Ansatz setzt anders an: vollständige Projekt-Übernahme statt Teilaufgaben, saubere Fundamente vor visueller Geschwindigkeit, Produktionstauglichkeit als Lieferzustand und nicht als Phase-2. Das kostet in der ersten Woche etwas mehr als ein generierter Click-Dummy. In Monat sechs ist es der Unterschied zwischen einem System, das wirkt, und einem, das ersetzt werden muss.
Mein Vorgehen
Vier Prinzipien, die den Unterschied machen zwischen einem Projekt, das pünktlich live geht und stabil bleibt, und einem, das in der Produktion auffällt:
01Discovery vor Code. Bevor ein Stack gewählt oder ein Prototyp gebaut wird, schauen wir gemeinsam auf Ihren Prozess, Ihre Nutzer und Ihre Constraints. Manchmal zeigt sich, dass die richtige Lösung weniger Software braucht als zunächst gedacht — das ist eine ehrliche Antwort, kein Verkaufstrick. Sie wissen am Ende, was warum gebaut wird, und was bewusst weggelassen wird, weil es Ihrem Geschäft nicht hilft.
02Komplettverantwortung statt Teilaufgaben. Backend, Frontend, Datenbank, Tests, CI/CD, Monitoring — eine Hand, eine Verantwortung. Sie sind nicht plötzlich Projekt-Koordinator zwischen vier Lieferanten, sondern haben einen Ansprechpartner, der die Übersicht behält und Entscheidungen konsistent über alle Schichten trifft. Auch die Dev-Umgebung wird mit aufgebaut oder mitgestaltet — nicht 'irgendwann später' geklärt.
03Saubere Fundamente vor sichtbarer Geschwindigkeit. Eine durchdachte Datenmodellierung, klare Domain-Grenzen, einheitliche Fehlerbehandlung — das sind die Dinge, die in den ersten Wochen Zeit kosten und in den ersten Jahren Geld sparen. Time-to-Market richtig gemacht heißt nicht: schneller Demo. Es heißt: schneller in stabilem Produktionsbetrieb, mit weniger Notfall-Aufwand danach.
04Bestehende Prozesse respektieren. Wo Ihr Workflow funktioniert, baut die Lösung drum herum statt ihn zu ersetzen. Eine Software, die Ihr Team zwingt umzudenken, wird selten akzeptiert — egal wie elegant der Code darunter ist. Moderne Werkzeuge (auch AI-gestützte) kommen dort zum Einsatz, wo sie Output messbar steigern; die Verantwortung für Architektur, Code und Entscheidungen bleibt beim Menschen.
Was Sie konkret bekommen
Vollständige Projekt-Übernahme
Backend, Frontend, Datenbank, CI/CD-Pipeline, Monitoring, Logging — alles aus einer Hand. Ob als Komplett-Übernahme oder als Senior-Architekt, der ein bestehendes Team und seine Entwicklungs-Umgebung mit aufbaut: Sie bekommen jemanden, der über alle Schichten konsistent entscheidet, statt fünf Spezialisten, die nur ihren eigenen Ausschnitt kennen.
Discovery-Phase vor jedem Projekt
Gemeinsame Analyse Ihres Use-Cases, bevor Architektur-Entscheidungen fallen. Am Ende dieser Phase wissen Sie: was wird gebaut, warum, mit welchem Aufwand — und genauso wichtig, was nicht gebaut wird, weil es Ihrem Geschäft nicht hilft. Kein Black-Box-Angebot, keine Versprechen ins Blaue.
Saubere Fundamente, Produktionstauglichkeit ab Tag eins
Datenmodell, Domain-Grenzen, Fehlerbehandlung und Beobachtbarkeit gehören in die Architektur, nicht in den Backlog. Was geliefert wird, läuft in Ihrer Umgebung — nicht nur im Demo-Setup. Tests, Monitoring und Deployment-Pipeline sind Teil der Lieferung. So bleibt das System auch nach dem dritten Release wartbar und führt nicht zur typischen Frage, wer denn jetzt um drei Uhr morgens dran ist.
Lösung nach Maß statt Vorlage
Architektur und Stack folgen Ihrem Use-Case, nicht dem Lieblings-Framework des Lieferanten. Wenn Ihr Bedarf 'einfach und stabil' heißt, werden keine Microservices um des Patterns willen gebaut. Wenn er 'mehrere Datenquellen kohärent verbinden' heißt, gibt es eine saubere Integrations-Architektur — ohne Overhead, der niemandem dient.
Übergabe ohne Vendor-Lock
Architecture Decision Records, automatisierte Tests, Onboarding-Dokumentation. Sie können das System nach Projektende selbst weiterführen oder mit einem anderen Team weiterentwickeln — ohne Wissensverlust, ohne Abhängigkeit von einem Lieferanten. Strukturelle Vorsorge statt Marketing-Floskel.
Aus der Praxis
Quickmail Systems — wenn Standard-Software nicht reicht
Schweizer Postdienstleister mit einer Sonderanforderung, für die es kein Produkt von der Stange gab: Mobile Apps für Zusteller in Bergregionen ohne stabile Mobilfunk-Abdeckung. Eine Standard-Lösung hätte hier nur halb funktioniert — mit Datenverlust bei jeder Funkloch-Strecke. Statt das Problem zu beschönigen, wurde gezielt entwickelt, was der Use-Case verlangte: eine eigene Offline-First-Sync-Engine, drei Sprachen, saubere Integration in bestehende Backoffice-Prozesse. Über vier Jahre sind sechs eigenständige Lösungen entstanden, alle bis heute in der Schweiz im täglichen Einsatz. Kein Big-Bang-Rollout, sondern schrittweise Erweiterung um die echten Bedürfnisse der Zusteller herum.
„Ich kann Christian nur Empfehlen. Wir hatten ein tolles Projekt bei einem Technologie Konzern. Christian ist für mich der perfekte Freiberufler: flexibel, spezialisiert, clever und sympathisch. Ich hoffe wir arbeiten bald mal wieder zusammen!"
Marcel Theunissen — IT-Vermittler & Berater, Finance, HR und Engineering
Was Sie sich vielleicht fragen
Wie lange dauert die Discovery-Phase?
Je nach Projekt-Komplexität zwischen wenigen Tagen und zwei Wochen. Bei klar umrissenen Use-Cases reicht oft ein gemeinsamer Workshop plus zwei, drei vertiefende Gespräche. Bei komplexeren Setups mit vielen Stakeholdern entsprechend mehr — aber immer mit klarem Ergebnis am Ende, nicht open-ended.
Was passiert, wenn die Discovery zeigt, dass das Projekt anders gemacht werden sollte als gedacht?
Dann sage ich das. Das ist genau der Punkt der Discovery: bevor Vertrag und Aufwand stehen, herauszufinden, ob die geplante Richtung trägt. Lieber zwei Tage neu sortieren als sechs Monate in die falsche Richtung bauen. Das gehört zur Beratungs-Verantwortung dazu, nicht erst zum Projekt-Auftrag.
Sie sind solo — was passiert, wenn Sie ausfallen?
Berechtigte Frage. Jeder Mandant wird so dokumentiert (Architecture Decision Records, automatisierte Tests, Übergabe-Doku), dass im Notfall ein anderer Senior das System übernehmen kann — ohne tage- oder wochenlanges Reverse-Engineering. Das ist Teil der Lieferung, nicht Optional-Extra. Für längere Engagements lässt sich zusätzlich eine Team-Aufstellung mit vertrauten Kollegen vereinbaren.
Wo passt diese Arbeitsweise nicht?
Wenn Sie eine Standard-Lösung suchen, die Sie zu 80% übernehmen können, sind Sie mit einem Produkt-Anbieter besser bedient. Wenn Sie reine Umsetzungskapazität ohne Architektur-Verantwortung brauchen — Body-Leasing für isolierte Feature-Tickets — gibt es darauf spezialisierte Dienstleister mit Junior-Mid-Mix, die das günstiger machen. Was sehr wohl passt: bestehende Systeme analysieren, optimieren oder schrittweise modernisieren. Dann ist die Discovery anders (Bestandsaufnahme statt grüne Wiese), aber das Vorgehen bleibt gleich — erst verstehen, dann ändern, mit klarer Architektur-Verantwortung.
Was kostet das?
Tagessatz im Marktbereich für Senior-Cloud-Architekten in DACH — transparent kalkuliert, abhängig von Engagement-Modell (kontinuierlich, projektbezogen, beratend). Die Discovery-Phase ist klein und planbar; danach gibt es ein konkretes Angebot mit Umfang und Zeitrahmen, nicht ein open-ended T&M-Projekt. Wenn aus der Discovery klar wird, dass es nicht passt, zahlen Sie nur die Discovery — kein Zwang zur Fortsetzung.
Klingt nach deinem Projekt?
Ein paar gezielte Fragen statt starres Formular — ich verstehe in 2–3 Minuten, worum es geht, und melde mich persönlich.