H-Studio logo
Projekt starten
Berlin Studio · Projekt-Rettung & Software-Übernahme

Ihr Software-Projekt steckt fest.
Wir übernehmen die technische Lage ab hier.

Eine gescheiterte Lieferung, ein abgewanderter Entwickler, ein stockendes Rewrite, eine fehlende Übergabe — wir übernehmen die technische Lage, stellen fest, was tatsächlich vorhanden ist, und geben Ihnen einen Recovery-Weg, der Ihnen gehört. Mit dokumentierten Befunden. Mit kontrolliertem Zugriff. Ohne Vendor-Lock-in. Wo Repository- oder Infrastruktur-Zugriff unvollständig ist, kann eine Wiederherstellung nicht garantiert werden — aber der Weg, festzustellen, was wiederherstellbar ist, ist strukturiert und explizit.

Erstes Reaktionsziel: innerhalb von 2 Berliner Geschäftszeitstunden, soweit Kapazität verfügbarErster Triage-Pfad: vorbereitet nach NDA und ausreichendem technischem ZugriffDeep-Dive-Ergebnis: schriftliche Recovery-Empfehlung, die Sie jedem technischen Team übergeben können
Gescheiterte Übergabe · Stockendes Rewrite · Abgewanderter Entwickler · Fehlender Repository-Zugriff · Nicht reagierender oder insolventer Lieferant· Berlin · DACH · 2h-Reaktionsziel (in Geschäftszeiten)

Reaktionsziele hängen von der aktuellen Kapazität ab und beginnen erst, sobald der erforderliche Zugriff und die NDA vorliegen. Ein System, das wir nicht gesehen haben, können wir nicht vorab beurteilen; wo der Zugriff unvollständig ist, kann eine Wiederherstellung nicht garantiert werden.

Engagement
Gegenseitige NDA vor Zugriff · Repository, Server und Infrastruktur über kontrollierte Übergabe
Triage
Sechs Achsen: Security, Deployability, Datenintegrität, Code-Qualität, Infrastruktur, Team-Übergabe
Ergebnis
Schriftliche Recovery-Empfehlung, die Sie jedem technischen Team übergeben können — Ihrem oder einem anderen
Reaktionsziel
Erste Reaktion innerhalb von 2 Berliner Geschäftszeitstunden, soweit Kapazität verfügbar
Ausgewählte H-Studio Mandant:innen und Projekte in DACH und international
My Office AsiaForschungsmittelVulken FMGRIDWenzelFolluMy Office AsiaForschungsmittelVulken FMGRIDWenzelFollu
Typische Situationen, in die wir einsteigen · 01

Typische Situationen, in die wir einsteigen.

Die meisten Engagements beginnen mit einem der folgenden Muster. Der Bewertungs-Rahmen ist in jedem Fall derselbe — wir benennen die Situation nur, um das erste Gespräch zu rahmen.

01

Gescheiterte externe Lieferung

Ein externes Lieferteam hat etwas gebaut, das nicht funktioniert, antwortet nicht mehr oder hat nie ein lauffähiges Release erreicht. Die Leitung braucht eine klare technische Entscheidung darüber, was existiert und ob es vorankommen kann.

Repository-ZugriffProduktions-ZustandEhrliche Scope-Einschätzung
02

Abgewanderter Entwickler

Ein einzelner Entwickler oder ein kleines Team hat ein internes System über Jahre gebaut und gepflegt und ist dann gegangen. Der Code ist undokumentiert und niemand auf Ihrer Seite versteht ihn aktuell.

Wissens-WiederherstellungBaseline-DokumentationStabilisierung & Onboarding
03

Stockendes Rewrite oder Migration

Ein internes Rewrite oder eine Migration läuft seit Monaten, ohne live zu gehen. Die Leitung braucht eine Außenmeinung dazu, ob fortgeführt, gerettet oder gestoppt werden soll.

Außen-SichtRettung vs. NeubauPhasen-Recovery-Plan
04

Nicht reagierender oder insolventer Lieferant

Der Lieferant ist in die Insolvenz gegangen, hat das Team gewechselt oder antwortet schlicht nicht mehr. Sie müssen Codebasis, Repository und Infrastruktur kontrolliert übernehmen.

Kontrollierte ÜbergabeRepository- & Infrastruktur-ZugriffKontinuitäts-Plan
Wann es passt — und wann nicht · 02

Wir übernehmen reale Engineering-Lagen. Nicht jede Lage ist eine Rettung.

Rettungsarbeit ist kontrolliert, Senior-geführt und bewusst eng im Scope. Bevor wir beginnen, stellen wir sicher, dass die Situation eine ist, die wir tatsächlich bewegen können.

Passt, wenn
  • Ein Dienstleister, Freelancer oder eine Agentur nicht mehr antwortet, in die Insolvenz gegangen ist oder etwas geliefert hat, das nicht funktioniert.
  • Ein internes Rewrite oder eine Migration ins Stocken geraten ist und die Leitung eine Außenmeinung dazu braucht, ob fortgeführt, gerettet oder gestoppt werden soll.
  • Ein langjährig zuständiger Entwickler abgewandert ist und aktuell niemand in Ihrem Team den Code oder die Infrastruktur versteht.
  • Ein Lieferant Ihr Repository oder Ihre Infrastruktur hält und Sie eine kontrollierte Übergabe in Ihr eigenes Eigentum brauchen.
Weniger passend, wenn
  • Sie laufende Wartung eines gesunden Systems brauchen — das ist Platform Support, keine Rettung.
  • Sie einen Neubau oder eine Modernisierung eines noch funktionierenden Systems planen — das ist Software-Modernisierung, oder Startup-MVP-Entwicklung für ein frühes Produkt.
  • Der Konflikt vorrangig rechtlich oder vertraglich ist (Lizenz, IP, Vertrag) und nicht technisch — das gehört zu Ihrem Counsel; wir stimmen uns ab, übernehmen aber keine rechtliche Federführung.
  • Sie eine Rettungs-Zusicherung vor jedem Zugriff erwarten — per Definition unmöglich; vor dem System-Einblick gibt es keine ehrliche Antwort.
Was Sie aus der Bewertung bekommen · 03

Eine erste Triage beantwortet: ist das rettbar?
Ein schriftlicher Deep-Dive beantwortet: wie sieht Recovery aus?

Zwei kompakte Bewertungs-Schritte vor jeder größeren Verpflichtung. Beide liefern schriftliches, übergebbares Ergebnis. Sie können nach beiden Schritten aussteigen und die Empfehlung mit einem anderen Team verwenden.

01

Repository- & Infrastruktur-Zugriff unter NDA

Gegenseitige NDA vor jedem Code- oder System-Zugriff. Wir stimmen uns mit allen ab, die noch Zugangsdaten, Hosting-Accounts oder Source-Control-Logins halten. Bei teilweise verlorenem Zugriff helfen wir dabei, abzubilden, was sich über Hosting, Repository-Anbieter, Deployments, Backups und Account-Eigentums-Nachweis wiederherstellen lässt — eine Wiederherstellung ist nicht garantiert, aber der Weg ist strukturiert.

02

Sechs-Achsen-Triage

Security-Exposition, Deployability, Datenintegrität, Code-Qualität, Infrastruktur-Zustand, Team-Übergabe-Tauglichkeit. Jede Achse bekommt eine kurze schriftliche Einschätzung plus eine Vertrauens-Notiz. Ziel ist, sichtbar zu machen, was tatsächlich vorhanden ist — nicht zu benoten.

03

Recovery-Entscheidung und Prioritäten-Karte

Eine klare Einschätzung, ob das System wiederherstellbar ist und in welcher Reihenfolge die kritische Arbeit passieren muss. Die Begründung wird explizit gemacht, damit Sie — oder jedes andere Team — danach handeln können, ohne uns auf das Wort glauben zu müssen.

04

Schriftliche Deep-Dive-Empfehlung

Architektur-Audit, Tech-Debt-Inventar, Liste kritischer Fixes sowie eine Empfehlung: Wiederherstellung, Teil-Neubau, kompletter Neubau oder Stopp. Als übergebbares Dokument geliefert, das Sie jedem technischen Team geben können.

05

Kein Lock-in by design

Nach dem Deep-Dive haben Sie eine schriftliche Empfehlung, die Sie jedem anderen Team übergeben können. Wir halten niemals Code als Geisel. Die Diagnose ist eigenständig wertvoll — auch wenn Sie mit uns weitermachen, gehört Ihnen das Dokument.

Wie ein Rettungs-Engagement fortschreitet · 04

Wie ein Rettungs-Engagement fortschreitet.
Nach jedem Schritt aufhören oder in die Recovery weitergehen.

Eine kontrollierte Abfolge, kein festes Paket. Jeder Schritt erzeugt schriftliches Ergebnis, das Ihnen gehört. Die Fortsetzung ist immer Ihre Entscheidung — nie eine automatische Bedingung der Bewertung.

Schritt 01

Zugriff und technisches Framing

  • Gegenseitige NDA vor jedem Zugriff
  • Repository-, Server- und Infrastruktur-Übergabe koordinieren
  • Abbilden, welcher Zugriff besteht und was noch wiederhergestellt werden muss

Ein klares Bild davon, was Sie tatsächlich haben, und ein kontrollierter Weg zum Rest. Wo der Zugriff unvollständig ist, sagen wir das klar.

Schritt 02

Erste Triage

  • Sechs-Achsen-Technik-Einschätzung (Security, Deployability, Datenintegrität, Code-Qualität, Infrastruktur, Übergabe)
  • Kurze schriftliche Einschätzung je Achse mit Vertrauens-Notiz
  • Schriftliche Zusammenfassung und ein Call

Eine ehrliche, schriftliche Einschätzung, ob das System rettbar ist, die Sie intern teilen können.

Schritt 03

Schriftliche Recovery-Empfehlung

  • Architektur-Audit und Tech-Debt-Inventar
  • Liste kritischer Fixes und eine Prioritäten-Karte
  • Empfehlung: Wiederherstellung, Teil-Neubau, kompletter Neubau oder Stopp

Eine übergebbare Recovery-Empfehlung, die Sie jedem technischen Team geben können — unserem oder einem anderen.

Schritt 04

Optionale Fortsetzung

  • Übernahme und Stabilisierung des Systems
  • Phasen-Recovery oder paralleler Neubau
  • Senior Engineering-Lead durchgängig

Ein Weg von einem steckengebliebenen oder kaputten System zu einem stabilen, eigenen Setup — nur wenn Sie sich für die Fortsetzung entscheiden.

Der Scope hängt von Systemzustand, Zugriffssituation, Integrationen und Recovery-Anforderungen ab. Wir bestätigen den Scope jedes Schritts schriftlich, bevor er beginnt.

Wie ein Rettungs-Engagement läuft

Ein definierter Ausstieg an jedem Schritt.

Jeder Schritt hat ein definiertes Ergebnis. Sie können nach jedem Schritt aussteigen — ohne Folgeverpflichtung. Das Timing hängt von der Zugriffslage ab und wird nie vorab zugesichert, bevor wir das System gesehen haben.

  1. Erstkontakt
    Erstgespräch, Situations-Framing, gegenseitige NDA
  2. Nach NDA und Zugriffs-Verfügbarkeit
    Zugriff einrichten: Repository, Server, Infrastruktur, Accounts — soweit verfügbar
  3. Sobald ausreichender technischer Zugriff vorliegt
    Sechs-Achsen-Triage, schriftliche Zusammenfassung und Call
  4. Wenn ein schriftlicher Deep-Dive beauftragt wird
    Architektur-Audit und schriftliche Recovery-Empfehlung
  5. Optionale Stabilisierungsphase
    Übernahme und Stabilisierung des Systems
  6. Optionale Phasen-Recovery oder Neubau
    Phasen-Recovery oder paralleler Neubau
Senior-geführt · 05

Senior-geführt von der ersten Bewertung bis zur Recovery-Entscheidung.

H-Studio Berlin ist ein Engineering-Studio, kein Body-Shop. Rettungsarbeit braucht besonders Senior-Urteilsvermögen — die erste Bewertung setzt den Rahmen für alles, was folgt, und das ist nicht die Aufgabe eines Junior mit Checkliste.

Jede Rettung wird von Senior-Engineering geführt, von der ersten Bewertung bis zur Recovery-Entscheidung. Dahinter steht das übrige Engineering-Team — aber Sie landen nie in einer Account-Manager-Kette.

Reaktionsziele hängen von der aktuellen Kapazität ab und beginnen erst, sobald der erforderliche Zugriff und die NDA vorliegen. Sind wir an der Kapazitätsgrenze, sagen wir das im ersten Call — statt zu strecken.

· Berlin· DACH· EU-Hosting-Optionen· NDA vor Zugriff
Cases · 06Alle Cases →

Angrenzende Engineering- und Recovery-Arbeit.

Vier Plates aus dem Studio-Archiv — eine ausgefaltet, drei daneben gepinnt. Jede ist ein reales Produktionssystem, kein Case-Study-Template.

Enterprise · DE

Vulken FM

Enterprise Facility-Management

Case lesen
Mittelstand · DE

Wenzel Group

Industrielle B2B-Plattform & Tooling

Case lesen
FAQ · 07

Rettungs-Fragen,
die wir am häufigsten hören.

Wovon hängt der Scope eines Rettungs-Engagements ab?

Der Scope folgt dem System, nicht einem festen Paket. Die Zugriffssituation, Größe und Zustand der Codebasis, die beteiligten Integrationen und der gewünschte Recovery-Umfang prägen ihn. Wir rahmen den ersten Schritt eng — Zugriff herstellen und eine erste Triage durchführen — und bestätigen den Scope jedes weiteren Schritts schriftlich, bevor er beginnt.

Was, wenn der bisherige Dienstleister sich weigert, den Code herauszugeben?

Das kennen wir. Erster Schritt ist eine klare, schriftliche Herausgabe-Anforderung mit Verweis auf Ihren Vertrag. Wenn das nicht hilft, arbeiten wir mit dem, was deployed ist — Produktionscode extrahieren, Verhalten dokumentieren, wo nötig per Reverse Engineering nachbauen. Eine rechtliche Eskalation entscheiden Sie; wir kümmern uns darum, dass das Projekt unabhängig davon vorankommt.

Was, wenn wir keinen Zugriff mehr auf unseren eigenen Server haben?

In den meisten Fällen lösbar. Hosting-Anbieter stellen Zugang für den rechtmäßigen Inhaber wieder her. Sind die Zugangsdaten wirklich verloren, arbeiten wir mit dem Anbieter an der Identitätsprüfung. Im schlechtesten Fall — Server zerstört, keine Backups — prüfen wir, was sich aus anderswo liegenden Kopien wiederherstellen lässt. Wo der Zugriff nicht wiederhergestellt werden kann, ist eine Wiederherstellung nicht garantiert, und das sagen wir klar.

Was, wenn es überhaupt keine Dokumentation gibt?

Häufig der Fall. Der Deep-Dive enthält die Erstellung einer Basis-Dokumentation: Architektur-Überblick, Deployment-Runbook, Datenmodell, kritische Pfade. Sie gehen mit etwas, das Sie jedem technischen Team übergeben können.

Was, wenn die Codebasis in einer Sprache ist, die niemand mehr verwendet (Delphi, Perl, ColdFusion, VB6)?

Wir haben mit älteren Stacks gearbeitet. Die erste Entscheidung ist, ob das System kurz auf dem Legacy-Stack weiter gepflegt wird, während eine moderne Ablösung entsteht — oder ob ein paralleler Neubau ab Tag eins gestartet wird. Beides ist tragfähig; die richtige Antwort hängt vom Betriebsrisiko ab und davon, wie lange das Altsystem laufen darf.

Was ist der Unterschied zwischen der ersten Triage und dem Deep-Dive?

Die erste Triage beantwortet 'ist das rettbar und wie groß ist es ungefähr?' über eine Sechs-Achsen-Technik-Einschätzung. Der Deep-Dive erstellt die eigentliche Recovery-Empfehlung — Architektur-Audit, Tech-Debt-Inventar, Prioritäten-Karte und eine Wiederherstellung-/Neubau-/Stopp-Entscheidung, die Sie jedem technischen Team übergeben können.

Übernehmen und bauen Sie neu, oder bewerten Sie nur?

Beides ist möglich. Nach dem Deep-Dive entscheiden Sie: die schriftliche Empfehlung behalten und an ein anderes Team übergeben — oder mit uns in Stabilisierung und Recovery weitergehen. Wir machen die Fortsetzung nie zur Bedingung der Bewertung.

Was, wenn das Projekt tatsächlich nicht rettbar ist?

Manchmal ist die ehrliche Antwort: 'diese Codebasis nicht weiterführen, stattdessen aus den Anforderungen neu bauen.' Falls das die Schlussfolgerung ist, sagen wir das in der Deep-Dive-Empfehlung. Lieber verlieren wir das größere Engagement, als einen Salvage zu empfehlen, der sich nicht lohnt.

Kontakt · 08

Erzählen Sie, was feststeckt — wir antworten innerhalb von 2 Stunden in Berliner Arbeitszeit, soweit Kapazität verfügbar.

Beschreiben Sie die Situation per Formular oder E-Mail — aktueller Stand, was feststeckt, wer noch Zugriff hat. Es läuft in dieselbe Inbox, und eine gegenseitige NDA liegt vor, bevor wir Code oder System-Zugriff anschauen. Senden Sie keine Zugangsdaten, keinen Quellcode und keine sensiblen Produktionsdaten über das Anfrageformular oder Messaging-Kanäle.

H-Studio Berlin
Schmidstraße 2F-K · 10179 Berlin
Reaktionsziel: innerhalb von 2 Stunden · Berliner Geschäftszeit
großes

Zusammen Großes schaffen

Zwei weitere Situationen · ebenfalls rettbar

Verlorener Quellcode und Übergabe-Lücken.

Zwei Muster, die nicht zu den oben genannten passen, aber häufig genug vorkommen, um sie explizit zu nennen.

  1. 01

    Quellcode verloren oder beim Vendor

    Sie haben eine individuelle Lösung gekauft. Jetzt müssen Sie sie erweitern — aber der Quellcode ist entweder beim ursprünglichen Anbieter (der ihn nicht herausgibt) oder schlicht verloren. Sie brauchen eine Kombination aus Reverse-Engineering und Ersatz.

  2. 02

    Übergabe ohne Wissenstransfer

    Sie haben Repository und Zugänge erhalten, aber keine Dokumentation, keine Architektur-Übersicht und niemanden zum Fragen. Das System läuft, aber niemand auf Ihrer Seite kann es sicher verändern.

Anonymisierte Rettungen

Composite-Szenarien aus der Rescue-Praxis.

Geschichten kombinieren wiederkehrende Muster aus mehreren Rettungs-Engagements. Konkrete Mandanten-Namen, Zahlen, Branchen und Stack-Details sind anonymisiert oder kombiniert. Keine Garantie für ein bestimmtes Ergebnis.

B2B-SaaS-Startup · vor dem ersten Deploy stecken geblieben

Kein Production-Deploy. Wir haben übernommen, ein erstes Release für Nutzer ausgeliefert und anschließend volle Feature-Parität auf einem wartbaren Stack erreicht. Composite-Szenario aus mehreren Rettungs-Engagements.

Mittelständler · Solo-Entwickler weg

Nach Jahren beim internen CRM in Delphi. Wir haben einen Deep-Dive gemacht, vollständige Dokumentation erstellt und anschließend einen phasenweisen Neuaufbau auf einem modernen Stack durchgeführt. Composite-Szenario.

Fertigung-KMU · gescheiterte ERP-Ablösung

Eine gescheiterte ERP-Ablösung. Wir haben eine Triage gemacht, empfohlen den Rewrite NICHT zu Ende zu führen und stattdessen eine schrittweise Modernisierung um das Bestandssystem herum aufzusetzen. Composite-Szenario.

Die Beispiele bündeln wiederkehrende Muster aus mehreren Rettungs-Engagements. Konkrete Mandanten-Namen, Zahlen, Branchen und Stack-Details sind anonymisiert oder kombiniert. Keine Garantie für ein bestimmtes Ergebnis.