SaaS-Projekt übernehmen lassen: Prüfung vor dem Neustart

Wenn ein SaaS-Projekt stockt, ist die wichtigste Frage nicht sofort die Wahl eines neuen Frameworks. Zunächst muss erkennbar werden, was bereits funktioniert, was fehlt und welche Risiken den nächsten Produktivschritt verhindern. Ein Dienstleisterwechsel braucht deshalb eine technische und fachliche Erstaufnahme. Dazu gehören ausführbarer Quellcode, dokumentierte Zugänge, Datenmodelle, Testbarkeit und die tatsächlich benötigten Nutzerabläufe.

Ausgangslage und Projektgrenzen

• Unterscheiden Sie einen demonstrierbaren Prototyp von einem betreibbaren Softwareprodukt mit reproduzierbarem Build, Testdaten und dokumentierter Veröffentlichung.
• Erfassen Sie bereits zahlende Kunden, vertraglich zugesagte Funktionen und betroffene Mandanten, bevor neue Produktideen priorisiert werden.
• Klären Sie Verfügbarkeit und Nutzungsrechte für Quellcode, Design, Abhängigkeiten und Infrastrukturzugänge mit den zuständigen Verantwortlichen.

Bewerten Sie bestehende Bausteine anhand konkreter Nutzungsszenarien. Lässt sich die Anwendung reproduzierbar bauen und ausliefern? Sind Mandanten und Berechtigungen sauber getrennt? Gibt es nachvollziehbare Datenmigrationen, Sicherungen und Wiederherstellungswege? Die Entscheidung zwischen Weiterentwicklung und Ersatz sollte einzelne Bereiche betreffen, statt vorschnell die gesamte Anwendung neu zu bauen. Ein priorisierter Maßnahmenplan trennt Produktlücken, technische Risiken und spätere Verbesserungen.

Architektur, Risiken und Aufwandstreiber

• Prüfen Sie Mandantentrennung nicht nur an Oberflächenfiltern, sondern an Datenzugriff, Hintergrundjobs, Dateispeicherung und Exporten.
• Untersuchen Sie Datenmigrationen und Veröffentlichungsprozesse: Ein Rollback des Codes stellt eine geänderte Datenbank nicht automatisch wieder her.
• Priorisieren Sie Produktfehler nach Geschäftsauswirkung.

Ein instabiles Onboarding oder verlorene Abrechnungsereignisse können wichtiger sein als ein großer Architekturumbau.

Die veröffentlichte GSWE-Case-Study AGRAChoice beschreibt genau eine solche Ausgangslage: Ein SaaS-Nachrichtendienst hatte ein vorhandenes Backend, aber noch kein nutzbares Frontend und keine belastbare Betriebsstruktur. GSWE ergänzte die Oberfläche, stabilisierte Backend und Integrationen und führte das Produkt bis zur Marktreife weiter. Die Referenz belegt die Übernahme und Vervollständigung; konkrete Umsatz- oder Zeitgewinne sind dort nicht quantifiziert.

Konkrete Prüffälle für den ersten Release

• Ein neuer Mandant wird mit einem eigenen Administratorkonto eingerichtet. Weder Suche noch Exporte enthalten Daten anderer Kunden.
• Das Produkt wird auf einer frischen Umgebung aus dem Repository gebaut. Erforderliche manuelle Schritte und fehlende Konfiguration werden sichtbar dokumentiert.
• Ein abgebrochener Hintergrundjob wird erneut ausgeführt. Der Kunde erhält kein doppeltes Ergebnis und der Bearbeitungsstand bleibt nachvollziehbar.

Für die Übergabe sind Repository, Abhängigkeiten, Infrastrukturzugänge und verantwortliche Ansprechpartner erforderlich. Vereinbaren Sie, wie offene Fehler, Entscheidungen und Zugangsdaten dokumentiert übergeben werden. Definieren Sie einen überprüfbaren ersten Release: welche Nutzer welche Aufgabe erfolgreich erledigen können und wie der Betrieb danach betreut wird. Die bloße Anzahl geschlossener Tickets ist kein ausreichendes Abnahmekriterium.

Fordern Sie als Ergebnis der Übernahmeprüfung einen reproduzierbaren Build, einen überprüften Wiederherstellungsweg und eine priorisierte Liste der größten technischen Risiken. Trennen Sie dafür Zugangsprobleme, fehlendes Fachwissen und tatsächliche Codefehler. Klären Sie, welche Funktionen während der Übergabe weiterentwickelt werden müssen und wer Releases freigibt. Erst mit dieser Grundlage lässt sich entscheiden, ob Stabilisierung, schrittweise Modernisierung oder die Ablösung einzelner Komponenten wirtschaftlich sinnvoll ist.

Eine Übernahme ist erst belastbar, wenn ein zweites Team die Anwendung aus der Dokumentation heraus bauen und in einer isolierten Umgebung starten kann. Definieren Sie eine Übergangsphase mit klaren Ansprechpartnern für kritische Fehler.

Entscheidungshilfe für die Beauftragung

• Verlangen Sie einen priorisierten Übernahmebericht mit konkreten Risiken, vorhandener Substanz und einem prüfbaren ersten Lieferumfang.
• Trennen Sie notwendige Stabilisierung, Produktweiterentwicklung und optionalen Technologiewechsel in der Planung.
• Vereinbaren Sie Wissenstransfer, Dokumentation und Zugriffshoheit, damit eine spätere Übergabe nicht erneut von Einzelpersonen abhängt.

Für ein vergleichbares Angebot

• Vorhandenen Produktstand, versprochene Kundenabläufe und offene Go-live-Hindernisse zeigen.
• Mandantentrennung, Onboarding, Integrationen und Betriebszugänge praktisch prüfen.
• Fertigstellungslücken priorisieren und für den ersten betreibbaren Release eine Abnahme vereinbaren.

Dabei darf eine ehrliche Bewertung auch ergeben, dass einzelne Teile ersetzt werden müssen. Entscheidend ist ein nachvollziehbarer Weg von der vorhandenen Substanz zu einem nutzbaren Produkt, mit klar priorisierten Risiken und einem Betriebsmodell, das zum Auftraggeber passt.

Nutzen bewerten und den Ausbau begrenzen

• Bewerten Sie die Übernahme an reproduzierbaren Releases, behobenen kritischen Abläufen und einer nachvollziehbaren Produktplanung.
• Ein kompletter Neubau braucht eine eigene Begründung anhand von Risiken und Migrationsaufwand; vorhandener Code ist zunächst zu prüfen.
• Erheben Sie Fehlerquote beim Onboarding und Zeit bis zur ersten nutzbaren Kundenfunktion als konkrete Signale für Produktreife.

Zeigen Sie GSWE den aktuellen SaaS-Produktstand und die Hindernisse für den ersten Kundenstart. Wir trennen Fertigstellung, technische Stabilisierung und Betriebsübergang für einen überprüfbaren Übernahmeauftrag.

Ein unfertiges SaaS-Produkt übernehmen lassen: SaaS-Übernahme mit geordnetem Produktivstart.